On Tue, 19 Nov 2002, Oliver Neukum wrote: > > My experience with the HID driver was that once it grabbed the device I > > couldn't do much with it, in particular I couldn't go in and tell it to
> You can't simply change settings from under a running driver. > It's a bad idea even in principle. We have a model which has drivers I agree, that's one reason I gave up on this path early. > bind to and claim an interface for a reason. If you need this, add > the feature to the hid driver. ok.... > > 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 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). 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. > > 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? 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 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? > > 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). - 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. Which again brings me back to issues raised in my original post: I've written a driver which people are beginning to use. I didn't actually think that it would be ready to go into the kernel in its current state (or even slightly improved based on your feedback), however the API I've developed requires both ioctls and a minor device ID. I've not yet recognized an argument for a better approach, but these are clearly finite resources and I would like to avoid conflict with other devices I don't yet know about. The numbers I'm currently using are essentially random, but now would be a good time to change them to something rational. Perhaps a solution would be to supply ranges of ioctls and minor device IDs for (USB) drivers which remain 'under development'? very best, rob. ------------------------------------------------------- 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
