> > > absolute mouse worked (this is still a load option for my module) --
> > > but the behaviour isn't what I wanted for a mouse. OTOH, absolute
> > > coords
> >
> > No, if the device generates absolute coordinates, report them.
> > There's no use in lying.
>
> I do not know of a layer or method for X which will translate abs to rel
> coords for the pointing device (please suggest one if you know), but
That looks like a job for gpm.
> relative mouse motion is what everyone seems to be used to; I thought an
> absolute mouse would be preferable but, after a while, it wasn't.
> Absolute coordinates are the right thing to work with internally to
> support more complex behaviours, and they can be converted to relative
> coordinates -- but not vice-versa. It's not lying, its converting to the
> appropriate data format expected by a key application (X windows).
Nevertheless, that's not kernel work. The device is an absolute mouse.
We have standards on how to present absolute mice. Use them.
> There's a more minor conversion required for the abs coords to work
> anyway, the device reports relative coords in its 'minimalist' mode, and
> this _is_ the mouse that is built into the laptop.
There's nothing wrong with using the device as a simple mouse,
if the device supports such a mode of operation. But then leave it
to the standard hid driver.
> > > Finally, one of my goals was to isolate and filter writes to the bulk
> > > endpoint to some extent -- if a sequence starting with '01 01' is
> > > written,
> >
> > Yes, you need to filter this. This means you need a kernel driver.
> > Security must be done in kernel.
>
> then I'm missing something fundamental here -- can I have two device
> drivers accessing the same interface on the same USB device?
You probably technically speaking could. Usbcore doesn't check
for having claimed the interface whose endpoint you are talking to.
But you shouldn't do this. It's a terrible mess.
> Specifically, you suggest above that the correct action would be to modify
> the hid driver to support supplying an alternate setting other than the
> default of '0'. Then hid will presumably handle the interrupt endpoint
Yes, but that's independent of other issues. The device has three settings.
There should be a way to use them. On the other hand setting settings
is something a driver should have absolute control over, so doing this
through usbfs is bad. Therefore I'd say do it in hid.
That probably means an ioctl. Well, live isn't perfect.
> and pass mouse data to X (skipping issues around absolute coords for now).
> Separate from this, another driver will bind to the bulk in/out endpoints
> on this interface and support filtering plus the LCD and backlight
> functionality. If hid keeps the bulk endpoints, then it must have a lot
> of device specific code/tables to support filtering and specialised
> commands?
Hid should not be concerned with stuff not in the hid specifications.
You have the choice now of having two drivers use the same interface
or a specialised driver for one device.
Given the choice I'd strongly prefer the latter solution, but I am certainly open
for discussion on this. Neither solution is good.
> > > there is too much flexibility in the controller commands to want (or be
> > > able) to limit actions here with many predefined routines.
> >
> > Again, it's a display, so write an fb driver.
>
> Yes, I've thought this as well. The two immediate issues are:
>
> - I'm currently writing 1 URB per scan line, but Windows appears to be
> sending 4kb URBs with most of an image. How can I do this under Linux?
> (I tried to describe this in my original message on this thread).
Pass a buffer large enough. Are you saying that Windows sends more
than the maximum size at once ?
> - based on my naive user knowledge, the frame buffer doesn't actually
> address the LCD controller complexity I would like to see supported,
> specifically multiple display layers which can be combined in various ways
> and an internal character generator. I've not been able to work out the
> initialisation to access these features, so in the mean time I wrote a
> simpler driver which enables more people to experiment with the device
> safely.
Well, there's nothing wrong with exporting a physical device as an input
device, a framebuffer and a special character device for extended features.
Regards
Oliver
-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
