Simon Thum escreveu: > Keith Packard wrote: >> Why does inserting events do anything but pull events from the kernel, >> insert them to the queue and update the sprite location on the screen? >> All event processing should happen in the main server thread; the only >> latency we're looking to reduce is the mouse->sprite update. > It's really not much: Middle button emu, translation/acceleration, ... > The point being their guts are exposed via input properties. Most cases > are trivial, which reads 'fairly safe given properly aligned writes are > atomic'. For the rest, there should be provisions (like suppressing > input processing) or a clear statement against complicated stuff in > props. At least, that's my opinion.
(Just to note: my last patch totally ignores the eventual races issues with input thread and input device properties) Sh*t, the things are starting to get confused again. Keith was right saying that the IT needs only to worry with sprite updates, and we're _not_ doing this right now. The input thread covers all the input event generation stage and more other bits. A problem that I see is in GetPointerEvents() function. It's bloated and confusing. It generates X events and also updates the cursor on screen. We don't need to mix this two actions in one function. For instance, I did a quickly hack here calling miPointerSetPosition() directly from evdev driver (!) instead inside GPE and apparently all worked nice. So if we could only put in a separate thread the pieces that deal with cursor's update and not related with X events then we'd be winning -- I failed to not see this before :( On the other hand, if we're moving to the kernel the pieces of our stack which are close with hw interaction, then it'd be more logical to move also all this not-window-related stuff to the kernel (inside drm, etc) and forget the input thread for all eternity. So yeah, I have to think a little more about this all. I think I still have a breath to start adventure again in kernel side. Cheers, -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br _______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg