> This doesn't make any sense - perhaps you don't understand what I meant by > "hiddev".
> Linux support is layered. The host controller talks to the PCI hardware. In > turn, the device driver talks to the host controller. The device driver for > HID devices is called hid. It exports two interfaces, which you can build > independent of each other - a char device of the form /dev/usb/hiddev0 to > /dev/usb/hiddev31, and an in-kernel interface to the input subsystem. > See http://www.linux-usb.org/linux.conf.au.02/talk/html/slide_11.html > > Now, you can either > 1. modify the hid driver to ignore your particular device, and implement a > framebuffer driver. > 2. modify the hid driver to add a third interface to some framebuffer API > code. > 3. work in userspace, and talk to the device over a char interface called > hiddev. > Sorry, I had really not understood what you meant by "hiddev". The device is actually a panel having a LCD controller and a touchscreen (single device address). So I planned to provide a char interface (say /dev/usb/panel) similar to the "/dev/usb/hiddev?", you have mentioned. I want to send data to the LCD controller using Bulk pipe and get data from the touchscreen using Interrupt pipe. The code of "usbmouse.c" was of great help for the touchscreen part. In the case of LCD, I find fbdev module in the X server, opeing /dev/fb and issuing ioctls for getting screen info, setting colormap etc. As per your point (3) above, I can change this fbdev module of the X server and talk to the /dev/usb/panel directly. But don't you think I will have to duplicate lots of generic linux frame buffer code (drivers/video/fb*) into my driver? > I completely fail to understand what you are trying to accomplish through an > in-kernel framebuffer driver. X drivers normally live in userspace for a good > reason. You certainly don't need a framebuffer for speed reasons, so why take > on all the issues associated with working in the kernel, and re-implementing > bits of the hid parser, and writing a framebuffer driver (where all the > framebuffer code is changing really fast on 2.5), when the underlying > hardware isn't a framebuffer at all? > Do you suggest to bypass the framebuffer completely and send commands (corresponding to framebuffer ioctls) to the device (provided the device supports it)? I am completely new to USB so please bear with me. Thanks, Manoj. _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
