> We're planning on using Vojtech's new input mechanism (most generally > fleshed out for USB devices, but it's always been intended for general > use) to deal with input devices in the future on Linux, and will be > retargeting the iPAQ's touch screen driver interface to this interface.
Yeah!!!!! I know some time ago I attempted to rewrite the h3600 touchscreen to the input api. Unfortunely I never had enough time to complete it. > We plan to use the low level event interface provided, rather than the > more cooked (typically for backward compatibility) interfaces, as it looks > like it should greatly help with coming devices on desktop systems and > support of the X Input extension. We should no longer have to teach X > about one device at a time, rather the kernel provides more abstract > interfaces for classes of devices we can leverage. Great. Because for 2.5.X will input devices will be moved over to this api. This includes every keyboard as well. The dave jones tree already has a bunch of devices converted over to the input api. I'm pushing maintainers on other platforms to port their keyboards over. As a side note also the console system will under go changes since it will be input api based internally. This means raw/medium keyboard mode will go away for linux. It will be considered obsolete. Use the event interface instead. This will also allow use to use a X server without needing a console system. You can use the event interface without a console system. It just the console system WILL need the input api. I look forward to the day when we will have direct input for OpenGL for real time respond with games. > o clients will have to rescale themselves (using the kernel's > calibration data) rather than the scaling in the kernel the > way the current iPAQ driver does. This turns out to aid rather > than hurt dealing with XInput, so we can get to the point where > a calibration program is just a vanilla X client, and deal with > screen rotation transparently (since the X server knows about > rotation at any given instant). Non X people will have to do > their own rescaling of event data. I'm glad doing userland scaling helps XInput because I and Vojtech didn't approve of scaling driver side. > o The input interface will be widened in two minor ways: > 1) user programs will be able to set the calibration data. > (either make the EVIOCGABS ioctl RW or add a new ioctl). > Pavel doesn't care which, but, of course, reserves the > right to change it if it isn't what he wants :-). What? I think you misunderstood the use of EVIOCGABS. That returns the range of values the hardware can generate. Those values are used internally in the input system to filter out junk. Sometimes hardware can give you errous data so those fields filter that. > 2) user programs (e.g. calibration programs) will signal > to clients of the input interfaces the calibration has > been changed by writing a reset event (the input stuff > broadcasts this to all clients using the new input > event mechanism). Clients that care to respond to new > calibration data will then read the calibration data and > rescale. Again are you dealing with hardware that would reprogram itself to change the range of values it would produce for events? > o new input devices will get signalled to the X server via > the hotplug mechanism, precise details TBD. It is there where > policy will get set as to whether an input device gets handed > to X or left alone to be used directly by other programs; we hope > leveraging the work that is going on there on setting policy > on how new devices get recognized/installed/configured. It shoudn't matter for read incoming events if a bunch of programs, X and other things, would use the event interface at the same time. It is writing that does matter. Then we get into a per process state that is stored. _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
