On Wed, Mar 23, 2011 at 3:36 AM, Eduard Hasenleithner <[email protected]>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.
>
> >> >> * 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 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
