[ANNOUNCE] xf86-input-evdev 2.2.99.1

[Maxim Levitsky]

On Fri, 2009-08-14 at 14:23 +1000, Peter Hutterer wrote:
> Removing xorg-announce from CC, if you want to follow this thread but you're
> not subscribed to xorg@, here's the original message:
> http://lists.freedesktop.org/archives/xorg/2009-August/046885.html
> 
> On Fri, Aug 14, 2009 at 06:09:56AM +0300, Maxim Levitsky wrote:
> > On Fri, 2009-08-14 at 12:20 +1000, Peter Hutterer wrote:
> > > This is a snapshot of the current evdev development tree.
> > > 
> > > The driver is stable for everyday use but will see further changes before
> > > settling down into 2.3. This snapshot intends to encourage wider testing.
> > > 
> > > Most notable changes to the current stable evdev 2.2:
> > > - The driver now honours EV_SYN. This avoids button events to be sent before
> > >   the associated motion events.
> > > - Slightly improved tablet support. Wacom and waltop tablets now post all
> > >   axes. Needs more work though.
> > > - More verbose log output for easier bug triaging.
> > > - Support for button and/or scroll-wheel-only input devices (e.g. Griffin
> > >   Powermate). Note that the server does not yet support them as
> > >   well.
> > > 
> > > Supports X Servers 1.5, 1.6 and git.
> > > 
> > > Bugs can be reported at https://bugs.freedesktop.org/enter_bug.cgi?product=xorg
> > > Component Input/evdev.
> > 
> > Folks, I have two outstanding questions about this driver.
> > 
> > First, I have seen that XI2 input is landed in master (and I enjoy two
> > mouses now :-)
> > 
> > But, there were rumors that this will enable support for 32 bit
> > keycodes, and it will be transparent, providing an updated Xlib is
> > installed. 
> > How far we are from that?
> 
> I doubt this will happen. Xlib itself is tightly paired with the core X
> protocol which has 8 bit keycodes. Making this transparent looks simple
> (Xlib itself uses ints) but would require numerous hooks within the library
> to call out into new requests where possible.  The devil's in the detail
> here.
Then, I phrase my question differently, when the X will report 32 bit
keycodes to userspace via *any* interface, so toolkits can be ported?
(I of course mean that events should originate from evdev)

> 
> > And what about joysticks, how they be handled in future, you plan?
> > Currently evdev just grabs them, and uses them as a mouse, and this
> > isn't funny, as this causes a sudden mouse movements due to noise from
> > the joystick (and crashes...)
> 
> if it's a crash, please file a bug so it can be fixed. I don't have any
> joystick devices.
Crashes that I have seen, ordinate, from sudden movements + compiz. This
probably pushes intel graphics stack too hard, and it isn't really easy
to capture


> 
> if you want devices to not be handled by evdev, you need to exclude them
> explicitly. See https://fedoraproject.org/wiki/Input_device_configuration
> we also have the xf86-input-joystick driver which is actively maintained and
> should be used for joystick devices.
Well, this isn't an answer, I know about that, and this isn't what I
have asked. I asked about the default, about the fact that X shouldn't
touch joysticks, if all it can to is to turn them into mouses. However
if you want to make X primary agent in joystick handling (which I would
welcome), then major users should be ported to use it, and /dev/js be
depricated.

If the older status is to remain, its fine, but then evedev should
blacklist the joysticks.


Best regards,
	Maxim Levitsky