On Tue, Mar 22, 2011 at 10:47:12PM +0100, Eduard Hasenleithner wrote:
> 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".
>
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.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?
I don't think it'd be a problem to include cairo.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
