On Wed, Mar 23, 2011 at 11:36:25AM +0100, Eduard Hasenleithner 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.
it's probably best to ask on linux-input/lkml what the preferred approach for this solution is. that way you have a clear path towards getting your patch merged > >> >> * 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. we could probably hook up the driver somehow to deal with pixmap changes but I think that's over the top and not needed. a write-only property sees good enough then. > >> 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. so, talking to Dave Airlie, 4-bit grayscale is unlikely to be supported. parsing more common formats is needed then. the PixmapRec struct used in the server has a pointer to the raw pixel data, the rest from there should be reaonably trivial. (I am not dealing much with output-related problems so I can't offer much expertise here) Cheers, Peter > >> >> +#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? ------------------------------------------------------------------------------ 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
