<scanty>
anybody catch my BAlert bug from yesterday?
linuxuser01 has quit [Quit: WeeChat 4.6.3]
tuaris has quit [Quit: tuaris]
Blurgh has joined #haiku
jnn has joined #haiku
jn has quit [Ping timeout: 480 seconds]
OscarL has joined #haiku
<OscarL>
waddlesplash: saw your latest patch. tried it on the N2600. triggered kdl by repeated calls to cpuid. First (current) KDL reads: "PANIC: never can get here".
<waddlesplash>
wow
<OscarL>
will save a picture of it.
<waddlesplash>
something is just really broken on your system right now lol
<waddlesplash>
I don't know that anyone's ever triggered that one
<OscarL>
got the same panic earlier today, but not as "first" KDL.
<waddlesplash>
can you try booting with both cpuidle modules blocklisted?
<OscarL>
(as long as I'm still able to guess what I read... I'm experiencing a scintillating scotoma, and parts of my visual field just aren't there :-/)
<OscarL>
booring up with both cstates modules disabled. repeated calls to cpuid sent me again into: ASSERT FAILED for that "waiter.thread == __null".
<OscarL>
sc looks the same as before.
<OscarL>
s/booring/booting/
Aedil has joined #haiku
<OscarL>
"co" sent me again to the same assert, next "co" have me the "recursive_lock 0xffff.... unlocked by non-holder thread!"
<OscarL>
will need to leave further testing for tomorrow, seems like I'm about to get a migraine, so I better try to sleep over it.
<OscarL>
Thanks for your work, waddlesplash. See you around.
OscarL has quit []
AD_Haiku_onPC has quit [Read error: Connection reset by peer]
<Jookia>
phschafft: to continue yesterday's conversation, exposing the widget tree as an IAccessible2 interface is what currently accessibility frameworks do. applications can do this using accesskit, on unix using dbus. applications then use this to interrogate the application to read its widgets, or to control it
* phschafft
nods.
<Jookia>
this approach has a lot of drawbacks
<Jookia>
i think if haiku wanted to support accessibility well it would have to support this framework
<phschafft>
hm?
linuxmaster has quit [Quit: Leaving.]
<Jookia>
but i don't know. is a GUI really just a set of well defined widgets in a tree?
<phschafft>
what else do you think there is?
<Jookia>
ad-hoc widgets that don't make sense
<phschafft>
such as?
<Jookia>
if you go to a site like github the top right has a search bar with text in it that when you open shows a menu with titles and rich text and then a second menu with other links and you use arrows to scroll through some and tab through the other
<phschafft>
I mean we can skip those things already that are bad ideas to begin with. so I wonder what the overlap of non-bad (!= good) ideas and non-welldefined-widgets is.
<phschafft>
but I mean in the end that is just a search input and a menu? just that it has some fancy rendering?
<Habbie>
Jookia, all of those are in a tree still
<Jookia>
some search things let you add tags to the search bar
<Habbie>
(but the tree is not always guaranteed to make sense to a human)
<Jookia>
so the search bar isn't just text, it's tags too. which might have like images in them and things like that
<Jookia>
the world is full of custom widgets
<phschafft>
but that is just rendering? and therefore exactly what we strip here?
<Jookia>
only the application knows how important all of these elements are
<phschafft>
yes. but if you mark that thing as a search bar (which it might already be) then you can still have 'good base support'.
<phschafft>
(in contrast to only fallback support)
<phschafft>
I mean custom widgets exist, totally.
<Jookia>
i don't think marking things is a good solution
<Jookia>
people forget to mark things
<Jookia>
or don't have ways to mark things
<phschafft>
the question is however are they custom in rendering, if that is the only difference then this can be ignored. they /look/ different, but if it is only rendering than it it is of no relevance to e.g. a blind person.
<phschafft>
if they are functionally different, then the fun begins.
HaikuUser has joined #haiku
<Jookia>
many many widgets are functionally different, the web is a very good example of this because most widgets are ad-hoc
<phschafft>
Jookia: I just say that as part of the web standards that one specific bar might be marked already, simply because it requires a type="" attribute anyway.
HaikuUser has quit []
<Jookia>
yeah that doesn't end up working very well
<phschafft>
I feel like you lost me somewhere.
<Jookia>
for instance, github marks the 'type slash to search' thing as a button
<Jookia>
it doesn't explain at all it's a search bar
<Jookia>
it also grabs focus so you can't tab to the menu links
<phschafft>
that all sounds like rendering to me?
<Jookia>
this is how it speaks to a screen reader i mean
<Jookia>
github marks it to announce as a button then grabs focus wrong and skips things in the reading
<Jookia>
i don't think application devs can be really trusted to make custom widgets
<Jookia>
or they shouldn't have to express them as a widget tree or something
<phschafft>
but if you look at it as a tree then... you don't have things like how the focus works as the interface software for the user has it's own mechanics?
<phschafft>
it looks to me a little like you are stuck somehwere in a middle ground.
<Jookia>
i'm describing the current situation
<phschafft>
between what it is as a GUI and what it might be.
<Jookia>
we have a tree of widgets but the widgets aren't well defined
<Jookia>
so it's more like a tree of garbage
<Jookia>
forcing devs to use a limited set of widgets would solve this, but also seems like something devs don't want
<phschafft>
I mean, if you want to give them the freedom to do whatever they want, then you will not solve any problem at all. ;)
<phschafft>
your goal and allowing them to do whatever they want are exclusive.
<phschafft>
with that, I need to take care of my flatmate for a little bit. happy to continue when I return. :)
<Jookia>
have fun
<phschafft>
It feels to me like you're bit stuck with your frustration and maybe need a good rant first before moving on. (which I totally understand :)
<Jookia>
i just think whatever solution there is must be apparent to devs and sighted people and controllable by them. which means putting the accessibility support in the application itself
<erysdren>
i mean, Jookia, to be honest most native Haiku applications dont have such bizzarre UI and technical design choices like many big modern websites do.
<erysdren>
in my opinion.
<erysdren>
i think it would be way easier to create a structured tree of GUI widgets in a native Haiku app than it would be a web browser.
<Jookia>
erysdren: yeah, it would be much easier. i dunno. someone would have to make a little screen reader for haiku too
HaikuUser has joined #haiku
<Jookia>
is there an actual tree of widgets in haiku's code somewhere?
HaikuUser2 has joined #haiku
<erysdren>
i'm not sure. i've only used the BeAPI a few times
<erysdren>
but necessarily, by how its programmed, they are in somewhat a tree formation. i think?
<Jookia>
i'm sure there probalby is some kind of scene graph internally right?
<erysdren>
i'm pretty sure widgets have parents
<erysdren>
not sure about all of them, but yeah
<erysdren>
more experienced Haiku programmers can correct me.
<Jookia>
maybe i could make a window to JSON dumper or something
<erysdren>
doing it at runtime would be the hardpart. you'd probably have to do hacks in libbe (seems unlikely) or convince your native Haiku app developers to use some library (maybe less unlikely)
HaikuUser2 has quit []
HaikuUser has quit []
* phschafft
points a xwininfo select cursor randomly at people.
<Jookia>
i might peek at the source code now
<erysdren>
waddlesplash, you on? any insight?
<Jookia>
i think it would be basically having a way to serialize a BView/BControl
<Jookia>
then sending updates whenever something changes
<Jookia>
but looking at the GUI API, there's no association with things like labels with other widgets
<erysdren>
unrelated to Haiku, but mainly for OscarL's interest: finally posted that doc i've been writing for the last few days, on the obscure 3D Studio VUE file format: https://erysdren.me/docs/vue/
nipos has left #haiku [Disconnected: Received SIGTERM]
nipos has joined #haiku
PetePete has quit [Read error: Connection reset by peer]
PetePete has joined #haiku
<Jookia>
phschafft: probably the first thing to do before any of that is to add support for a keyboard cursor in applications that let you move through on screen widgets. i don't think this needs a screen reader API or anything
<Jookia>
like an inspect/browse mode that switches between regular input and inspection input that lets you navigate around the screen and inspect different parts of a window
<Jookia>
screen readers usually do this in their own application but i think doing it in the UI toolkit is a better idea
<Jookia>
this would let people navigate/inspect the GUI structurally using a keyboard. this would benefit regular keyboard users too
<Jookia>
i think browsers call this 'caret browsing'
<Jookia>
maybe you could hit f7 in gui applications to switch to caret browsing and back?
* phschafft
nods.
<phschafft>
we call it cursor of death.
bjorkintosh has quit [Quit: "Every day, computers are making people easier to use." David Temkin]
<phschafft>
as sometimes the cursor gets like between two tiles on a map view or next to something that implies a huge text font even if there is no text (like inline flowing <img>s)
<phschafft>
so sometimes you have that fontsize 800pt cursor ;)
<Jookia>
i think having a way to navigate using keyboard hierarchical/structured using arrow keys, such as up meaning 'parent container' and down meaning 'child', left/right meaning 'sibling' and then the ability to go down to navigate text individually, having the GUI toolkit handle all of this would heavily simplify the screen reader as then we can just call TTS or something
<Jookia>
more importantly though it would allow sighted people to easily use it and test their programs/navigation
<Jookia>
then you could display in a debug box what the screen reader would read to the user and decide if that's correct
<Jookia>
this would also mean if you ever have custom widgets people could add support for this navigation/presentation and easily debug it
<Jookia>
though the downside is this would only work in haiku apps
<OscarL>
waddlesplash: added some comments on the waiter.thread == __null ticket. Other than that... x86_acpi_cstates on the Phenom II X4 have me this: https://bpa.st/AUZQ
<OscarL>
erysdren: nice write up on the VUE format! The bit about orthogonal views made me remember about using AutoCAD 10 on a 386sx (had to use a TSR x87 emulator :-/) around 1996 :-D
<OscarL>
erysdren: Liked reading about your work on Plush! I remember "discovering" it back in the days, among other nullsoft goodies (I never did anything with it, other than just reading the src, as I tend to do :-D).
<waddlesplash>
OscarL: I think the scheduler must be severely misbehaving on your system for some reason. The other asserts you reported indicate that
<OscarL>
erysdren: Idea for a Plush-engine based game...
<waddlesplash>
Either that, or the thread object is getting corrupted
<OscarL>
waddlesplash: the interesting part for me was being able to reproduce it not only on the N2600, but on the N450 too. No idea what to make out of it though :-)
<waddlesplash>
yes, that is very interesting
<OscarL>
erysdren: Isometric Sokoban in a spaceship... with some occasional alien-type enemy encounters!
<OscarL>
waddlesplash: I've tried underclocking the Phenom thinking... maybe it only happens with many slow cores, but couldn't trigger it there no matter what I've tried.
<OscarL>
erysdren: Without any "combat": one should defeat the alien by just "trapping" it with the boxes/blocks, or by completing the level before the enemy can catch the player. And that's all I can think of :-)
Aedil has joined #haiku
<OscarL>
waddlesplash: only other bit I found of interest so far was that "KERN: acpi cpu 3 maps to cpu 2" on the phenom. Will let you know if I found anything else on other machines.
<waddlesplash>
that's expected I think
<Begasus[m]>
re
<OscarL>
wb Begasus[m] :-)
<Begasus[m]>
Hola OscarL :)
<Begasus[m]>
k, no changes in the patchset for Qt6.9.2 PR :P
<OscarL>
waddlesplash: can't reproduce on the E-450. Might be Hyperthreading related?
<OscarL>
waddlesplash: A N455 based netbook refuses to boot from the pendrive that works OK on the N450, Phenom, and E-450, for some reason. These cheap "classmate PC" clones tend to have crappy firmware/BIOS :-(
<OscarL>
actual message is "bios_ia32 stage1: Failed to load OS. Press any key to reboot..." so fails even earlier than I've said before :-D (and this is after I re-built the pendrive partition, MBR, boot menu and such).
<OscarL>
will probably need to take out the HDD and install elswere if I want to try again on this one.
<Begasus[m]>
OK, new Qt library checked for upstream GCompris branch :)
<OscarL>
mmm, the N450 got stuck before lighting up the RAM icon now. Let's see what on-screen debug info shows on reboot.
<OscarL>
that "ieee80211_notify_scan_done" is annoying (pollutes the output too much).
<OscarL>
waddlesplash: with latest patch, on N450, both cstates modules disabled... on-screen-debug info shows many "usb_disk: aquire_sem failed while waiting for data transfer: Operation timed out", till after a while it ended up in KDL...
<waddlesplash>
lol
<OscarL>
"PANIC: no more requests for owner 0xffff...."
<waddlesplash>
so this is just usb_disk falling over on your hardware again, for unknown reasons
<OscarL>
will try a different port, and then on the N2600 (but installing the .hpkg on the HDD install)
<OscarL>
using a different USB port... booted into desktop (media_adon_server crashed, as it tends to do). Will try to trigger https://dev.haiku-os.org/ticket/19749
<OscarL>
yay!
<OscarL>
waddlesplash: assert failed on: scheduler_theard.h:413
<waddlesplash>
where?
<waddlesplash>
oh when you ran the test?
<OscarL>
ran cpuid a couple of times... until it triggered on the N450
<OscarL>
at least this one is from the last patch you gave me, right?
<OscarL>
awesome. Will give it a try waddlesplash. Thank you!
<waddlesplash>
the scenario this would imply shouldn't happen anyway
<waddlesplash>
but that's another problem
<waddlesplash>
OscarL: if you didn't start a build yet I have another patch
<waddlesplash>
to try and find the real root cause
<OscarL>
just executed cpuid on the N450...straight into KDL (but a longer one this time... sc got partially overwritten)
<waddlesplash>
ah
<OscarL>
what I can figure out is: intr_bottom -> x86_hardware_interrupt -> reschedule(int) -> enqueue(BKernel::Thread*, bool) -> Scheduler::ThreadData::ChooseCoreAndCPU(...) --> panic
absyn-th has joined #haiku
<OscarL>
will take a picture, as-is, and then try to use sc again to see if missed something else.
<OscarL>
feels like sending a fax would be faster than sending the image over bluetooth, sigh.
ADS_Sr has joined #haiku
<Jookia>
some notes. 'qemu-system-i386 -m 4G -cdrom ~/Downloads/haiku-r1beta5-x86_gcc2h-anyboot.iso' crashes with the smbios error
<Jookia>
i tried compiling haiku today but it just hangs at boot saying 'error starting /boot/system/servers/launch_daemon'
<waddlesplash>
there should be an error above that
<waddlesplash>
what profile did you use?
<Jookia>
@nightly-image
<Jookia>
but it also had build errors like
<Jookia>
'nothing provides haiku>=r1~beta5_hrev57937_5-1 needed by zlib-1.3.1-3'
<waddlesplash>
did you build without git tags?
<Jookia>
yes
<waddlesplash>
then this is the problem
<waddlesplash>
you need to specify a HAIKU_REVISION that's close to the real one if you don't do that
<waddlesplash>
if you specified some random value then that'll cause problems like this
<Jookia>
yes but it doesn't tell me what value it should be
<waddlesplash>
check the real git tags?
<waddlesplash>
if you cloned from github just pull from the real source to get them
<waddlesplash>
git pull --tags etc.
<Jookia>
i did git pull --tags but github doesn't have tags
<OscarL>
waddlesplash: sc from last KDL (with the scheduler.cpp.diff applied): https://ibb.co/ZzSXGwbZ
<waddlesplash>
Jookia: so clone from the real source like I said
mmu_man has joined #haiku
<waddlesplash>
git.haiku-os.org
<waddlesplash>
github is a mirror
<OscarL>
Jookia: you need to pull from review.haiku-os.org
<Jookia>
which one
<waddlesplash>
they're the same
<waddlesplash>
OscarL: that's a weird KDL
<waddlesplash>
should also be added to the ticket
<Jookia>
why are there two URLs then
<waddlesplash>
review is the HTTP for Gerrit
<waddlesplash>
git is a Cgit interface to the same repos
<waddlesplash>
anyway latest hrev is hrev59042
<waddlesplash>
you can just set that as HAIKU_REVISION
<Jookia>
do i have to do a clean reubild
<Jookia>
rebuild
<waddlesplash>
jam should probably figure out what to rebuild
<Jookia>
that doesn't seem to fix the issue
<Jookia>
i'll try a clean rebuild
<waddlesplash>
no SMBIOS crash with that command line with QEMU 10 here
<waddlesplash>
I wonder what the difference is
<waddlesplash>
Jookia: are you building with -q
<Jookia>
yes
<waddlesplash>
ok, good
<Jookia>
which seabios are you on
zardshard has left #haiku [#haiku]
jmairboeck has joined #haiku
zardshard has joined #haiku
PetePete has quit [Ping timeout: 480 seconds]
<Jookia>
ok, that fixed it
PetePete has joined #haiku
<waddlesplash>
Jookia: idk, whatever came with the qemu for windows installer
<Jookia>
ah
<Jookia>
waddlesplash: could you explain what is broken with paging/physical access mentioned the other day? or what i should investigate more?
<waddlesplash>
basically we should not get page faults on the physical side in vm_memcpy_physical
<waddlesplash>
if the physical page really exists then it should not fault
<waddlesplash>
if the page doesn't exist, it probably should ASSERT fail
<waddlesplash>
checking that may be tricky though... we'd need to check kernel_args ranges
<waddlesplash>
I guess if you see a way to fix the SMBIOS driver then just go with that first, and I'll take a look once you do and see if I can spot some other solution
<waddlesplash>
for the underlying problem
<Jookia>
i'm just wondering how i'd trigger the kernel fault easily for testing outside this
<waddlesplash>
outside what?
<Jookia>
outside the smbios bug
<Jookia>
if i fix that how would i test the vm_memcpy_physical issue
<waddlesplash>
if you want you should test that first
<waddlesplash>
or, it's easy enough to undo fixes later