Hello, Teemu Kuusisto, le jeu. 14 nov. 2019 14:09:15 +0200, a ecrit: > As a blind developer I would be very happy to use QEMU's baum chardev for a > braille display. Unfortunately, this device fails to detect the tty in which > the spice client is running.
Ah indeed that case was never looked at. > The current code calls qemu_console_get_window_id() to get the tty. > The code does not currently consider the fact that the lifetime of the > connected graphical consoles is not the same as the lifetime of the > VM. Indeed, with spice the situation is different. > This function returns zero, which causes the code to skip even the > default behavior of brlapi's brlapi__enterTtyMode() (including > checcking some env variables such as CONTROLVT) Mmm, indeed that should be fixed into letting brlapi try to find it, so that CONTROLVT can work. > window id sounds like something different than a tty number, maybe a > number of X display? Yes, under X you need to provide the X window id. > Is it possible to get callbacks for connect and disconnect of a > graphical console (like spice and vnc)? How? [...] > Such events should lead to calls of brlapi__EnterTtyMode() and > brlapi__leaveTtyMode(). That would seem to be the way to go indeed, but see below. > Is it further possible to get any information of the connected > client to determine the tty, and possibly sub-windows too (see > brlapi__enterTtyModeWithPath), in which the client is running? More precisely you would need to know the X window ID on the front-end side. The VNC and spice protocols don't currently provide this. Also when the VM and the frontend are running on different machines this would not make any sense anyway so I don't think it will get added to spice & vnc anyway. One ugly way to get it to work is to run the spice client and keep it open, get its X window id through xwininfo or equivalent, and only then start qemu with CONTROLVT set to that id. But of course you can't close the client and reopen it later. The way to properly fix it is to add a brlapi channel to spice: in addition to main, display, inputs, cursor, playback, and record channels, we would have a brlapi channel. The brlapi protocol is already packet-based, so that would work nicely. The server in qemu would list the brlapi channel in addition to others, and brlapi packets would flow over. The spice client would just forward brlapi packets over without modification, except for the enterttymode packet, in which it would just prepend its own windowpath and window id. The forwarding implementation could be implemented in libbrlapi so that spice clients don't have to maintain the support. Similarly, we could modify libbrlapi to not necessarily connect to the usual brlapi socket, but let the application provide send/recv functions to exchange the packets. Samuel
