[PATCH 2/4] X event queue mutex

[Tiago Vignatti]

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