On Mi, 2013-11-20 at 09:32 -0500, John Baboval wrote: > On 11/20/2013 03:12 AM, Gerd Hoffmann wrote: > > Hi, > > > >> I think you are only considering output here, for input we definitely > >> need some idea of screen layout, and this needs to be stored > >> somewhere. > > Oh yea, input. That needs quite some work for multihead / multiseat. > > > > I think we should *not* try to hack that into the ui. We should extend > > the input layer instead. > > This would be a contrast to how a real system works.
No. We have to solve problem here which doesn't exist on real hardware in the first place. > IMO, the UI is the > appropriate place for this sort of thing. A basic UI is going to be > sending relative events anyway. > > I think a "seat" should be a UI construct as well. A seat on real hardware is a group of input (kbd, mouse, tablet, ...) and output (display, speakers, ....) devices. In qemu the displays are represented by QemuConsoles. So to model real hardware we should put the QemuConsoles and input devices for a seat into a group. The ui displays some QemuConsole. If we tag input events with the QemuConsole the input layer can figure the correct input device which should receive the event according to the seat grouping. With absolute pointer events the whole thing becomes a bit more tricky as we have to map input from multiple displays (QemuConsoles) to a single absolute pointing device (usb tablet). This is what Dave wants the screen layout for. I still think the input layer is the place to do this transformation. While thinking about this: A completely different approach to tackle this would be to implement touchscreen emulation. So we don't have a single usb-tablet, but multiple (one per display) touch input devices. Then we can simply route absolute input events from this display as-is to that touch device and be done with it. No need to deal with coordinate transformations in qemu, the guest will deal with it. cheers, Gerd
