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? Cheers, Eduard ------------------------------------------------------------------------------ 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
