Re: [Linuxwacom-devel] [draft-patch] OLED setting for xsetwacom
On Wed, Mar 23, 2011 at 11:36:25AM +0100, Eduard Hasenleithner wrote: > 2011/3/23 Peter Hutterer : > > 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
Re: [Linuxwacom-devel] [draft-patch] OLED setting for xsetwacom
On Wed, Mar 23, 2011 at 01:48:45PM -0500, Favux ... wrote: > 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. http://lxr.linux.no/#linux+v2.6.38/Documentation/usb/proc_usb_info.txt "In many modern systems the usbfs filsystem isn't used at all. Instead USB device nodes are created under /dev/usb/ or someplace similar. The "devices" file is available in debugfs, typically as /sys/kernel/debug/usb/devices." http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483392 "Please consider to not mount /proc/bus/usb any more. It has been deprecated in favor of /dev/bus/usb long ago, which is much more flexible, configurable, and coherent to the spirit of /dev." commit cc71329b3b89b4a5be849b617f2c4f151f0b9213 Refs: v2.6.30-5441-gcc71329 "USB: usbfs: deprecate and hide option for !embedded Modern systems do not use usbfs; the entries within it are files, not device nodes, and do not support ACLs which are the default way to provide access to USB devices to untrusted users. It is replaced by device-nodes maintained by udev in /dev/bus/usb, libusb uses this device nodes. Mark the option as deprecated, and hide entirely for non-embedded builds (which may not be using udev but require raw USB device access)." Kconfig entry: "Modern Linux systems do not use this. Usbfs entries are files and not character devices; usbfs can't handle Access Control Lists (ACL) which are the default way to grant access to USB devices for untrusted users of a desktop system. The usbfs functionality is replaced by real device-nodes managed by udev. These nodes lived in /dev/bus/usb and are used by libusb." so yeah, I wouldn't rely on it :) Cheers, Peter -- 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 Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] [draft-patch] OLED setting for xsetwacom
On Wed, Mar 23, 2011 at 12:55 PM, Eduard Hasenleithner wrote: > Now I even tested the linuxwacom/src/2.6.30 driver on a fresh > linux-2.6.38 from kernel.org. I had to do a few minor modifications to > the driver source (ioctl has been renamed to unlocked_ioctl in > usb_device and input->abs is missing) but it works perfectly! > Apparently the driver did not diverge too much from the current > kernel. > If you can make a patchset against the latest Dmitry's input tree and submit it to linux-input mailing list for review, I will backport the support to input-wacom (after your patchset is accepted by linux-input). Thank you. 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 Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] [draft-patch] OLED setting for xsetwacom
Now I even tested the linuxwacom/src/2.6.30 driver on a fresh linux-2.6.38 from kernel.org. I had to do a few minor modifications to the driver source (ioctl has been renamed to unlocked_ioctl in usb_device and input->abs is missing) but it works perfectly! Apparently the driver did not diverge too much from the current kernel. 2011/3/23 Favux ... : > Interesting. That's why I didn't say anything earlier. Supposedly > you could use some symlinks to get around the lack of a /proc/bus/usb, > but we could never get that working. > > Launchpad bug report: > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/488274 Yeah, the bug report says that usbfs (i.e. mounted on /proc/bus/usb) causes problems with Ubuntu and therefore had to be disabled. The device nodes in /dev/bus/usb (i.e. "without" usbfs) provide access to the raw USB devices in the same way as /proc/bus/usb did. Maybe the usbfs provided some additional information about the usb raw devices. This information I get now from sysfs. 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 Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] [draft-patch] OLED setting for xsetwacom
Interesting. That's why I didn't say anything earlier. Supposedly you could use some symlinks to get around the lack of a /proc/bus/usb, but we could never get that working. Launchpad bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/488274 Favux On Wed, Mar 23, 2011 at 1:56 PM, Eduard Hasenleithner wrote: > 2011/3/23 Favux ... : >> 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. > > Very strange. I'm developing the xsetwacom led extensions on my Lucid > (kernel 2.6.32) install. And it works like a charm. Maybe there is > some misunderstanding about "dropped usbfs". In fact, usbfs was > dropped in the sense, that it is no longer possible to mount it on > /proc/bus/usb. Nevertheless, the functionality is still available > using /dev/bus/usb. > > br, > 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 Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] [draft-patch] OLED setting for xsetwacom
2011/3/23 Favux ... : > 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. Very strange. I'm developing the xsetwacom led extensions on my Lucid (kernel 2.6.32) install. And it works like a charm. Maybe there is some misunderstanding about "dropped usbfs". In fact, usbfs was dropped in the sense, that it is no longer possible to mount it on /proc/bus/usb. Nevertheless, the functionality is still available using /dev/bus/usb. br, 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 Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] [draft-patch] OLED setting for xsetwacom
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 wrote: > On Wed, Mar 23, 2011 at 3:36 AM, Eduard Hasenleithner > wrote: >> >> 2011/3/23 Peter Hutterer : >> > 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, an
Re: [Linuxwacom-devel] [draft-patch] OLED setting for xsetwacom
On Wed, Mar 23, 2011 at 3:36 AM, Eduard Hasenleithner wrote: > 2011/3/23 Peter Hutterer : > > 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 s
Re: [Linuxwacom-devel] [draft-patch] OLED setting for xsetwacom
2011/3/23 Peter Hutterer : > 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 Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] [draft-patch] OLED setting for xsetwacom
On Tue, Mar 22, 2011 at 10:47:12PM +0100, Eduard Hasenleithner wrote:
> 2011/3/22 Peter Hutterer :
> >> It defines a new pseudo-property "Wacom Button Image". When
> >> XChangeDeviceProperty is called with a 2049 octet data, the first
> >> octet is taken as the button number, and the remaining 2048 octets are
> >> taken as the image.
> >
> > this approach isn't all too different to the button mapping. It may be
> > better to have this nested, i.e. have the button image property contain
> > atoms that themselves contain the actual image data.
> >
> > so you have
> > Wacom Button Immage: 543 562
> > Wacom Image 1 (543):
> > Wacom Image 2 (562):
>
> In fact, I also thought about doing it similar to the button actions.
> But I discarded the idea when seeing that all "unspecific" Atoms are
> catched by the last "else" in the "if-else" chain by
> wcmSetActionProperties. Is it reasonable to continue the if-else
> chain, but compare the property-type instead of the property? So
> wcmSetActionProperties would catch properties of type XA_INTEGER and
> wcmSetButtonImage would catch properties of a type like "OLED IMAGE".
>
yes, of course.
> >> * It might be better to use libsysfs to access sysfs. Can we link against
> >> it?
> >
> > yes.
>
> Thanks, then I will then check if libsysfs fits the task.
I hope so, the string replacement approach seems a bit suboptimal.
> 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" ;)
> >> * 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.
> 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).
> >> +#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?
> >> +static void set_image(Display *dpy, XDevice *dev, param_t *param, int
> >> argc, char **argv)
> >> +{
> >> + int id, w, h, range, i;
> >> + Atom prop = None;
> >> + unsigned char data[2048+1];
> >> + unsigned char pixel[2];
> >> + char str[40];
> >> + FILE *f;
> >> +
> >> + sscanf(argv[0], "%hhd", data+0);
> >> + memset(data+1, id, sizeof data-1);
> >> + f = fopen(argv[1], "r");
> >> + fgets(str, sizeof str, f);
> >> + fscanf(f, "%d %d\n", &w, &h);
> >> + fscanf(f, "%d\n", &range);
> >> + for (i=1; i<2049; i++) {
> >> + fread(pixel, 1, sizeof pixel, f);
> >> + data[i] = pixel[0] >> 4;
> >> + }
> >> + fclose(f);
> >> + prop = XInternAtom(dpy, WACOM_PROP_BUTTON_IMAGE, True);
> >> + if (!prop)
> >> + {
> >> + fprintf(stderr, "WACOM_PROP_BUTTON_IMAGE not available");
> >> + return;
> >> + }
> >> + XChangeDeviceProperty(dpy, dev, prop, XA_INTEGER, 8,
> >> PropModeReplace, data, sizeof data);
> >> +}
> >> +
> >> static void set_xydefault(Display *dpy, XDevice *dev, param_t* param, int
> >> argc, char **argv)
> >> {
> >> Atom prop, type;
> >
> > The interface I'd like to see in xsetwacom is to have
> > xsetwacom set "device" ButtonImage 1 file.
Re: [Linuxwacom-devel] [draft-patch] OLED setting for xsetwacom
Hi
2011/3/22 Peter Hutterer :
>> It defines a new pseudo-property "Wacom Button Image". When
>> XChangeDeviceProperty is called with a 2049 octet data, the first
>> octet is taken as the button number, and the remaining 2048 octets are
>> taken as the image.
>
> this approach isn't all too different to the button mapping. It may be
> better to have this nested, i.e. have the button image property contain
> atoms that themselves contain the actual image data.
>
> so you have
> Wacom Button Immage: 543 562
> Wacom Image 1 (543):
> Wacom Image 2 (562):
In fact, I also thought about doing it similar to the button actions.
But I discarded the idea when seeing that all "unspecific" Atoms are
catched by the last "else" in the "if-else" chain by
wcmSetActionProperties. Is it reasonable to continue the if-else
chain, but compare the property-type instead of the property? So
wcmSetActionProperties would catch properties of type XA_INTEGER and
wcmSetButtonImage would catch properties of a type like "OLED IMAGE".
> (see pixmap comment below though)
>
>> Basic working principle:
>> * In wcmUSB.c, at device start (usbStart) the corresponding USB-FS bus
>> and device number is derived from the event device. This is done by
>> exploiting the layout of "sysfs". Starting at the event char device
>> "/sys/dev/char/major:minor" and going into the fourth parent directory
>> "../../../.." "busnum" and "devnum" can be read from USB-FS.
>> * In wcmXCommand, the Image is sent to the USB device by means of USB-FS.
>> * xsetwacom reads a PGM image file for setting the button image
>
> if you're introducing a new format, you should define it as a property and
> then use the Atom of this as type. This allows clients to make sure that the
> data they're uploading is correct.
> similar to the Floating property, in fact. that too isn't a predefined
> format but allocated at runtime by the server.
>> Questions:
>> * Is it possible to link to further libraries? E.g. it might be
>> convenient to have xsetwacom setting directly "text" to the buttons.
>
> yes. might make sense to support e.g. png in xsetwacom and convert
> internally. I think the easiest way to do this (especially when going the
> pixmap path) would be to use cairo.
Thanks for the pointer.
>> * It might be better to use libsysfs to access sysfs. Can we link against it?
>
> yes.
Thanks, then I will then check if libsysfs fits the task.
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 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.
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.
>> +#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.
>> +static void set_image(Display *dpy, XDevice *dev, param_t *param, int argc,
>> char **argv)
>> +{
>> + int id, w, h, range, i;
>> + Atom prop = None;
>> + unsigned char data[2048+1];
>> + unsigned char pixel[2];
>> + char str[40];
>> + FILE *f;
>> +
>> + sscanf(argv[0], "%hhd", data+0);
>> + memset(data+1, id, sizeof data-1);
>> + f = fopen(argv[1], "r");
>> + fgets(str, sizeof str, f);
>> + fscanf(f, "%d %d\n", &w, &h);
>> + fscanf(f, "%d\n", &range);
>> + for (i=1; i<2049; i++) {
>> + fread(pixel, 1, sizeof pixel, f);
>> + data[i] = pixel[0] >> 4;
>> + }
>> + fclose(f);
>> + prop = XInternAtom(dpy, WACOM_PROP_BUTTON_IMAGE, True);
>> + if (!prop)
>> + {
>> + fprintf(stderr, "WACOM_PROP_BUTTON_IMAGE not available");
>> + return;
>> + }
>> + XChangeDeviceProperty(dpy, dev, prop, XA_INTEGER, 8, PropModeReplace,
>> data, sizeof data);
>> +}
>>
Re: [Linuxwacom-devel] [draft-patch] OLED setting for xsetwacom
On Tue, Mar 22, 2011 at 12:13:13AM +0100, Eduard Hasenleithner wrote:
> Here I have a very early draft for setting the Intuos4 OLED display by
> means of xsetwacom.
nice work!
> It defines a new pseudo-property "Wacom Button Image". When
> XChangeDeviceProperty is called with a 2049 octet data, the first
> octet is taken as the button number, and the remaining 2048 octets are
> taken as the image.
this approach isn't all too different to the button mapping. It may be
better to have this nested, i.e. have the button image property contain
atoms that themselves contain the actual image data.
so you have
Wacom Button Immage: 543 562
Wacom Image 1 (543):
Wacom Image 2 (562):
(see pixmap comment below though)
> Basic working principle:
> * In wcmUSB.c, at device start (usbStart) the corresponding USB-FS bus
> and device number is derived from the event device. This is done by
> exploiting the layout of "sysfs". Starting at the event char device
> "/sys/dev/char/major:minor" and going into the fourth parent directory
> "../../../.." "busnum" and "devnum" can be read from USB-FS.
> * In wcmXCommand, the Image is sent to the USB device by means of USB-FS.
> * xsetwacom reads a PGM image file for setting the button image
if you're introducing a new format, you should define it as a property and
then use the Atom of this as type. This allows clients to make sure that the
data they're uploading is correct.
similar to the Floating property, in fact. that too isn't a predefined
format but allocated at runtime by the server.
>
> Current rough edges:
> * Relies on sysfs being present
> * Relies on sysfs being accessible using "/sys/dev/char/%d:%d/../../../../%s"
> * Relies on USB-FS "mounted" on /dev/bus/usb
> * No error checks yet
> * No comments
>
> The current version of this patch is not for inclusion into the x11
> wacom driver, but to show a "Proof of Concept" and to support
> discussion if LED support can be included in xsetwacom, and how it has
> to be done.
>
> Questions:
> * Is it possible to link to further libraries? E.g. it might be
> convenient to have xsetwacom setting directly "text" to the buttons.
yes. might make sense to support e.g. png in xsetwacom and convert
internally. I think the easiest way to do this (especially when going the
pixmap path) would be to use cairo.
> * It might be better to use libsysfs to access sysfs. Can we link against it?
yes.
> * Should all the Image functions be moved into a separate file (e.g.
> wcmButtonImage.c)?
yes please
> * 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.
> diff --git a/include/wacom-properties.h b/include/wacom-properties.h
> index dfa454d..023ab2c 100644
> --- a/include/wacom-properties.h
> +++ b/include/wacom-properties.h
> @@ -89,6 +89,7 @@
> if this button is pressed. If the value is None, no action is performed.
> */
> #define WACOM_PROP_BUTTON_ACTIONS "Wacom Button Actions"
> +#define WACOM_PROP_BUTTON_IMAGE "Wacom Button Image"
>
> /* 8 bit, 2 values, priv->debugLevel and common->debugLevel. This property
> * is for use in the driver only and only enabled if --enable-debug is
> diff --git a/src/wcmUSB.c b/src/wcmUSB.c
> index 06f8655..e2acf43 100644
> --- a/src/wcmUSB.c
> +++ b/src/wcmUSB.c
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #define MAX_USB_EVENTS 32
> @@ -127,10 +128,13 @@ static Bool usbDetect(InputInfoPtr pInfo)
>
> /*
> * usbStart --
>
> /
> +#define FORMAT "/sys/dev/char/%d:%d/../../../../%s"
> static int
> usbStart(InputInfoPtr pInfo)
> {
> int err;
> + WacomDevicePtr priv = (WacomDevicePtr)pInfo->private;
> + struct stat stat;
>
> #ifdef EVIOCGRAB
> /* Try to grab the event device so that data don't leak to
> /dev/input/mice */
> @@ -142,6 +146,21 @@ usbStart(InputInfoPtr pInfo)
> xf86Msg(X_ERROR, "%s: Wacom X driver can't grab event device
> (%s)\n",
> pInfo->name, strerror(errno));
> #endif
> +
> + if (fstat(pInfo->fd, &stat) >= 0) {
> + FILE *f;
> + char str[100];
> + snprintf(str, sizeof str, FORMAT,
> + major(stat.st_rdev), minor(stat.st_rdev), "busnum");
> + f = fopen(str, "r");
> + fscanf(f, "%hhd", &priv->usbdev_bus);
> + fclose(f);
> + snprintf(str, sizeof str, FORMAT,
> + major(stat.st_rdev), minor(stat.st_rdev), "devnum");
> + f = fopen(str, "r");
> + fscanf(f, "%hhd", &priv->usbdev_dev);
> + fclose(f
[Linuxwacom-devel] [draft-patch] OLED setting for xsetwacom
Hi Here I have a very early draft for setting the Intuos4 OLED display by means of xsetwacom. It defines a new pseudo-property "Wacom Button Image". When XChangeDeviceProperty is called with a 2049 octet data, the first octet is taken as the button number, and the remaining 2048 octets are taken as the image. Basic working principle: * In wcmUSB.c, at device start (usbStart) the corresponding USB-FS bus and device number is derived from the event device. This is done by exploiting the layout of "sysfs". Starting at the event char device "/sys/dev/char/major:minor" and going into the fourth parent directory "../../../.." "busnum" and "devnum" can be read from USB-FS. * In wcmXCommand, the Image is sent to the USB device by means of USB-FS. * xsetwacom reads a PGM image file for setting the button image Current rough edges: * Relies on sysfs being present * Relies on sysfs being accessible using "/sys/dev/char/%d:%d/../../../../%s" * Relies on USB-FS "mounted" on /dev/bus/usb * No error checks yet * No comments The current version of this patch is not for inclusion into the x11 wacom driver, but to show a "Proof of Concept" and to support discussion if LED support can be included in xsetwacom, and how it has to be done. Questions: * Is it possible to link to further libraries? E.g. it might be convenient to have xsetwacom setting directly "text" to the buttons. * It might be better to use libsysfs to access sysfs. Can we link against it? * Should all the Image functions be moved into a separate file (e.g. wcmButtonImage.c)? * Can we use the rendering capabilities of the X-server and send an PIXMAP by means of XChangeDeviceProperty? thanks, Eduard led.diff Description: Binary data -- 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 Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
