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 _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
