Luca Saiu, le Tue 21 Apr 2015 10:17:46 +0200, a écrit : > I suspect a workaround would consist in killing some brltty process > right before the lightdm greeter dies, so that the process presence > doesn't lock the device.
Err, that's not how things work: there's just one brltty daemon, which is never supposed to die, and one Orca process runs for the lightdm session and connects to brltty, and another Orca process runs for the user session and connects to brltty. > I packaged a recent version of lightdm and lightdm-gtk-greeter from > upstream, with a few (ugly) screen reading fixes. I don't have a > Braille terminal available to test, but a person using one reported > problems with respect to the accessibility of the lightdm session versus > the user session. > > In particular I would like to have a "virtual" Braille device, just to > be able to check whether the device responds or not. > Would you happen to have any tips for further investigation? You can either - enable the braille monitor in Orca - or use the xw driver of brltty, but that'll require another X display. - for debian installer debugging, I run the tested environment inside qemu with a virtual braille qemu device connected to brltty showing the virtual braille device. See https://wiki.debian.org/DebianInstaller/Accessibility for the details. - another way is to really use another X display: run an X server on another system, and set XAUTHORITY/xauth/xhost and DISPLAY appropriately. For instance, one can use an X server on a smartphone connected via wifi. Samuel -- To UNSUBSCRIBE, email to debian-accessibility-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150421083251.ga3...@type.bordeaux.inria.fr
