On Thu, 2 May 2002 23:02, Manoj Sharma wrote: > On Thu, 2 May 2002, Brad Hards wrote: > > Perhaps you write a userspace driver that talks to hiddev? > > No, I think I need to write a kernel module that talks to the hiddev. Then > only I can use the /dev/fb from user space. 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. 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? Brad _______________________________________________________________ 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
