Hi
2011/3/22 Peter Hutterer <[email protected]>:
>> 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): <image data>
> Wacom Image 2 (562): <image data>
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);
>> +}
>> +
>> 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.pgm
Yes, the draft code already works like that. E.g.
xsetwacom --set 'Wacom Intuos4 8x13 pad' Image 1 icon-alt.pgm
gives me an "Alt" text on button 2.
> instead of the button number hidden in the first byte. the button mapping
> code can work as an example here. and of course, parsing png or similar
> would be nice.
Thank you for the pointer to cairo, this library appears to fit the
task. A question is if this additional library requirements have to be
made optional in the configure.ac, or they can be mandatory for the
xf86-input-wacom?
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
