On Mon, Dec 12, 2005 at 01:22:38AM -0500, Dmitry Torokhov wrote: > On Sunday 11 December 2005 23:40, Ville Syrjälä wrote: > > On Sun, Dec 11, 2005 at 10:28:46PM -0500, Dmitry Torokhov wrote: > > > > > > Do you disable autorepeat on purpose? Because if you set repeat delay and > > > period by yourself you also need to provide your own timer handler. > > > > The hardware provides repeat events itself. I just ignore them if not > > enough time has elapsed. > > > > But you can't control hardware repeat rate, can you?
No, not really. But you can ignore some events thus in effect slowing down the rate. > If you leave that > to input core user can control the delay and repeat rate. Software repeat would allow more fine grained control and faster repeat rate than the hardware can provide. The hardware repeat rate is ~10 Hz which is rather slow but I don't think a fast repeat rate makes much sense with clumsy remote control buttons anyway. > > > > obj-$(CONFIG_USB_AIPTEK) += aiptek.o > > > > obj-$(CONFIG_USB_ATI_REMOTE) += ati_remote.o > > > > +obj-$(CONFIG_USB_ATI_REMOTE2) += ati_remote2.o > > > > > > I wonder - can these 2 drivers be folded into one? They seem somewhat > > > similar... > > > > They are more different than similar IMO. > > > > ati_remote hardware has one interface with one in and one out endpoint. > > ati_remote2 hardware has two interfaces with one in endpoint each. That > > means the init/exit code would need two code paths. > > > > ati_remote2 hardware handles mouse pad accel and keyboard repeat but > > ati_remote (I think) handles them in software. So the event handling > > would need two code paths. > > > > I am not convinced that we should rely on hardware repeat. I don't have much of an opinion on this issue. My initial idea was simply that since the hardware sends the repeat events in any case why not use them. > As fas as > initializationm goes you could attach driver-specific data controlling > initialization to the device ID table. That would unclutter init/exit > routine while allowing sharing bunch of the code. I'm not convinced combining the drivers has any real benefits. It would reduce the code size just a little a bit, but on the other hand it would grow the module size and make the code harder to follow. Actually it seems to me that the similarities of ati_remote and ati_remote2 can be found between almost any two USB input driver. The init/exit code and the urb complete callback always follow the same formula with some minor variations. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
