Hi, usbfs was deprecated in kernel 2.6.31 I think. Certainly by 2.6.32 Ubuntu (Lucid 10.04) and several other distributions dropped it. This all happened at about the same time. There was some conflict with changes in udev. Apparently since usbfs implicitly changes event behavior it was breaking the newer udev. Hence Christoph Karg's userland OLED app. (he just posted an update in linuxwacom-devel) and San's modifications of it for profiles and other stuff.
Favux On Wed, Mar 23, 2011 at 12:53 PM, Ping Cheng <[email protected]> wrote: > On Wed, Mar 23, 2011 at 3:36 AM, Eduard Hasenleithner <[email protected]> > wrote: >> >> 2011/3/23 Peter Hutterer <[email protected]>: >> > On Tue, Mar 22, 2011 at 10:47:12PM +0100, Eduard Hasenleithner wrote: >> >> For accessing USB-FS, I already considered libusb, just to find out >> >> that it does not (yet?) provide the USBDEVFS_IOCTL. Ideal would be >> >> IOCTL tunneling through the linux event subsystem in the kernel, but >> >> this is not supported by the linux event subsystem. >> > >> > can we make it so in the kernel? >> > (of course, by "we" I mean "you" ;) >> >> On one hand I consider my skills sufficient for adding an "ioctl >> passthrough" to the event subsystem. On a few occasions in the past, >> patches written by myself already went into the linux kernel. But on >> the other hand, I have no "channel" to the kernel maintainers of the >> input (and event) subsystem. From the kernel maintainers I often get >> the feeling they want as much as possible being done in Userspace. >> Therefore I would prefer - at least for now - not to rely on kernel >> infrastructure changes. >> >> >> >> * Can we use the rendering capabilities of the X-server and send an >> >> >> PIXMAP by means of XChangeDeviceProperty? >> >> > >> >> > I think this may be the best option though I need some confirmation >> >> > from the >> >> > graphics guys. That way the property code would be quite simple too, >> >> > the >> >> > property data is simply the drawable ID. >> >> >> >> One question is what happens to the drawable when xsetwacom exits. >> > >> > Depends on whether we want it to be write-only or read-write. if it's >> > write-only, we can delete it. otherwise, we need to leave it around so >> > that >> > you can read it later. >> > Pixmaps usually get deleted, but can be made permanent with >> > XSetCloseDownMode, afaict. >> >> >From my point of view, the image has also to be permanent for the >> write-only case. Changing a single image involves (like for the button >> actions) following steps >> 1. Read the list of Atoms >> 2. Change the Atom of the Image you want to change >> 3. Write the list of atoms again >> >> When the x11 wacom driver gets the new list of atoms, it also has to >> check the "untouched" images for changes. If they are already gone >> this might cause a problem. Or worse, wrong images are loaded onto the >> keys due to ID space collisions between subsequent xsetwacom >> invocations. >> >> It does not have to be that way, it is just that my X11 programming >> knowlege is now two weeks old, and is therefore not very solid. >> >> >> Another question is, if the drawable (4-bit gray) is supported by all >> >> (relevant) X-Servers and their display drivers (assuming that we don't >> >> want to write an additional display driver for the OLEDs of the >> >> tablet). PIXMAPs (1-bit) are supposed to be supported by all X-Servers >> >> though. Having written this, and although it might fit very well into >> >> the X11 Protocol semantics, using in-client rendering might be much >> >> easier and have less potential compatibility and handling problems. >> > >> > the important thing here: the pixmap does not necessarily have to be in >> > the >> > same format as the driver requires. the driver could do the pixel >> > transformation in-driver to support a more standard format 8 bit for >> > example (or even multiple formats if necessary). >> >> If this can be handled "straight-forward" in about 200 lines of code - >> fine. If it needs considerably more, or if the code is very fragile >> (e.g. breaks often due to XOrg code/driver changes) i'm hesitant to go >> that way. >> >> >> >> +#define WACOM_SET_LED_IMG _IOW(0x00, 0x00, struct wacom_led_img) >> >> >> +#define WACOM_SET_LEFT_HANDED _IOW(0x00, 0x01, struct >> >> >> wacom_handedness) >> >> >> +#define WACOM_SET_LED_MODE _IOW(0x00, 0x02, struct wacom_led_mode) >> >> > >> >> > the latter two don't seem to be used? >> >> >> >> Thats right. I assume, they should also be configurable through >> >> xsetwacom. Having LED image support is first on my priority list. In >> >> the end it might be better to include "wacom_wac.h" from the >> >> linuxwacom tree. >> > >> > while you mention linuxwacom - this code is going upstream, right? >> >> I'm not sure what you mean with "this code". The OLED patch in the >> wacom kernel driver was not written by myself, but by Nicolas Hirsch. >> I just submitted a patch to this mailing list, re-enabling the ioctl >> for kernel 2.6.30. I have no clue if, and when, the kernel driver from >> linuxwacom goes upstream to kernel.org. Maybe Ping does know? > > No, the code is not in kernel.org. No one is maintaining the code. Nicolas > haven't replied to the list for questions related to OLED for a while. He > has most likely unsubscribed from the mailing list, I think. > > Plus, the code can not be submitted to linux-input as is since users have > reported that the code doesn't work on newer kernels (I don't remember the > exact problems). That's why the code is not included in input-wacom for > xf86-input-wacom. > > Ping > > > ------------------------------------------------------------------------------ > Enable your software for Intel(R) Active Management Technology to meet the > growing manageability and security demands of your customers. Businesses > are taking advantage of Intel(R) vPro (TM) technology - will your software > be a part of the solution? Download the Intel(R) Manageability Checker > today! http://p.sf.net/sfu/intel-dev2devmar > _______________________________________________ > Linuxwacom-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel > > ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar _______________________________________________ Linuxwacom-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
