Wednesday, November 19, 2008

evdev 2.1 is out

After a (too) long wait, evdev 2.1 is finally out. This release should bring evdev up to speed and provide those features that the mouse driver had, but were previously missing from evdev. Get it while it's fresh.

One of the important things here (especially if you're a distributor): evdev 2.1 does not call EVIOCGRAB on the device anymore. Either patch it in again, or update your server to one that doesn't require it (1.5.3 will do).

Here's a short list of new features that have been added since 2.0:- axis inversion- touchscreen support (those that don't report BTN_LEFT)- run-time calibration for absolute devices- axis swapping- mouse wheel emulation- drag lock

Also included is property support for run-time configuration. We don't have a released server that provides this option yet, but it'll be good for a test-bed until 1.6 comes out.The properties also caused the long wait for the release, I wanted to wait until the server API had settled down. The next release will be sooner. The proposed release date for X server 1.6 is Jan 5 2009. Evdev 2.2 will be released by Jan 5 2009 as well.

8 comments:

Hi,the mouse driver's 3rd button emulation had to be deactivated because it introduced a lag (button press and mouse movement could be desync'ed). Is it still the case with evdev ? If yes, is there an option to deactivate that feature ?

I've got a question an answer on which I couldn't find (I'm ever blind or dumb or both).In "old" evdev (don't remember at what version that changed), it was highly recommended to NOT use option "Device" in xorg.conf in cooperation with evdev driver in input section, then after some time (past some versions) evdev become completely incompatible with "Device" option, and now after 2.0.7 it DEMAND that option ("Device") if configured using xorg.conf.And so the question is why?

HASH: early versions of evdev had their own hotplugging because the server didn't support it. This support was more of a hack than anything else.

Now the hotplugging is handled by HAL, so evdev doesn't need to hack around anymore. Option Device is required now, but OTOH in virtually all cases, no xorg.conf entry for input devices is needed in the first place.

Well ok, but I highly recommend to make evdev be able to work with ever option "Device" or "Name" (and "Phys", "Vendor", "Product") for situation where some one need to use evdev but not hal for auto detection of InputDevices.As there are such situations when one need to do so and here is example:There is a demon "btnx" which is main task is to configure and make support for additional button on "Logitech MX Revolution", this button is viewed for the system as a virtual keyboard with one button and that button is always report keycode XF86Search, so whenever I would describe any action for similar button on real keyboard which have search button I would make them both do that action, but I'd like to make so mouse button is acting as one action and keyboard as another, here comes btnx:You can configure btnx to produce any keyboard or mouse event on response to any other real device event, the events btnx produce is made through a virtual keyboard and mouse, but btnx need that real device it handles to not be seen and used by X-server.So the situation is simple:1. I need the X-server not to "see" that virtual keyboard made from "Logitech MX Revolution", but I can not to do so as it's autodetects it with hal.2. I can force xorg.conf configuration, but again I can't use this way because each time btnx starts it create new pair of devices with new input numbers so I can not use "Device" option to point xorg.conf on btnx devices and have to use "Name" + "Vendor" + "Product", but I can't...

And the final, not everyone "love" hal, but everyone happened to switch their USB keyboard and/or mouse from one USB port to another, and they each time need to edit xorg.conf for that? O_o