A friend of mine bought a laptop that unfortunately comes with an unsupported touchpad. The good news is that it comes with full documentation.
Is this documentation enough to make a driver with multi-touch support?
Is it advisable to base the driver from another (similar) touchpad driver as a starting point? If so, which one shall I use?
As far as I know, this controller is already supported by Linux. Just make sure your kernel version is recent enough to have the driver/input/mouse/byd.c source file, and that it is enabled by checking for the presence of the CONFIG_MOUSE_PS2_BYD token in your kernel configuration.
Related
I'm working on a project to investigate the possibility of adding touch support to an application and so far the findings have been somewhat disappointing. My company uses Scientific Linux 6.4 (Linux kernel 2.6.32) and so far, I've found information suggesting that 2.6.30+ supports multi-touch HID, but I've also seen information suggesting that the multi-touch in this kernel doesn't work with Xorg interfaces.
Putting aside market availability of touchscreens that are compatible with Linux, is there a way we can verify whether or not multi-touch inputs are generated on the system? We have an older ViewSonic touchscreen that has multi-touch capability, and after looking at the output from the evtest tool, I didn't notice any multi-touch events, but I don't know whether evtest is reading the touch events from X or the hardware level.
I have no experience dealing with hardware programming or device drivers, so if anyone could give me some guidance on how to verify multi-touch HID compatibility with our version of Linux, whether we have to write our own driver, or read raw data from somewhere, any information you could provide would be great.
EDIT: The evtest program lists supported events for the device and I don't see anything related to multi-touch, so it doesn't seem like it's supported, but is this an issue with the kernel, the specific device, or something else? The specific monitor I'm testing is a ViewSonic, which is listed as a "Quanta Optical Touchscreen" device. I saw somewhere that a driver for Quanta was added in 2.6.34. Am I just out of luck (for this particular device at least)?
I went ahead and tested the monitor with a laptop that had Linux kernel 4.4.0, and it worked right away, so it seems that it's definitely the kernel. I don't know if there are any touchscreens that WILL work with kernel 2.6.32, but the ones based on the Quanta display definitely don't work.
I want to write a driver for sensor which can tell me if my yoga 2 pro is in tablet mode or not.
I read some about writting modules but as far as I know, I need to know address in memory which belongs to this device (hope it's correct), and here is my question.
How can I find information about this address?
Or what should I do to find this address?
Both in Windows and in Android you absolutely don't need to write a driver for this purpose. To identify Tablet/Laptop mode, you need just one sensor - accelerometer. In Windows 8.1 + this functionality is built-in, but in case you wish to build your own application you can use an example from here: https://code.msdn.microsoft.com/windowsapps/Accelerometer-Sensor-Sample-22982671
In Android, you have a Java API to all sensors:
https://developer.android.com/guide/topics/sensors/sensors_overview.html
However if you have a custom Linux installed on your Yoga, there indeed may arise a need to add a driver. As of now, the most useful solution are IIO drivers that are part of Kernel:
http://events.linuxfoundation.org/sites/events/files/slides/lceu15_baluta.pdf
If there aren't already there, you'll have to rebuild a Kernel and include those drivers. If you don't know how to find a device address, you have to learn for a while about Linux Kernel in general. Anyway, some tips:
Sensors are normally defined via USB/HID interface
If you still have your Windows along with Linux, you may go to
Devices Manager and there you can easily reach Sensors and see what
address is used by a driver.
I am trying to setup a Tegra 3 (Toradex Apalis T30) based system that will have an OpenGL ES based user interface on a touch screen. Unfortunately the standard Linux4Tegra kernel is seriously outdated and the provided graphics driver requires X11 integration. I have found though that I can build the Vanilla Linux kernel and get it running just fine on my board (tested 3.18). I have also found that a DRM Tegra driver is included in the kernel these days and I enabled it in menuconfig and built the kernel using it. I have also managed to get many distros working with the kernel (though I haven't really tried getting X working on any one).
My problem is that beyond this point, I am stuck. I cannot figure out what to do next in order to get GLES rendering up and running with the DRM driver. I have looked around a bit and have seen that Mesa might support GLES via DRM but I am not sure if this will allow me to do so without X? Also, how on earth to I get Mesa configured and compiled for the Tegra DRM driver?
Also, how does one go about configuring the output display using this DRM driver? My target screen is a 24bit parallel RGB display but I have not got that hooked up yet and would like to test with HDMI first. I have literally no idea how one should go about configuring the output display. The only information that I can find that might help involves X and xorg.conf which I will hopefully not be using. My device does output the console correctly on the HDMI display, how does it know to do that? Might this process somehow involve the device tree?
PS. I guess this question is a bit stupid but I am very new to embedded Linux and have just figured out how to build the vanilla kernel etc. and have really no idea of how the Linux display system works beyond just configuring X. Finding information regarding this is also proving hard.
EDIT:
I have gotten XFCE sort of running on HDMI (login does not work and the login windows is very tiny) on Fedora using the OpenTegra driver which in term uses the DRM driver if I am not mistaken so hopefully that is good news?
Nvidia-setting can usually clear things up if you've gotten this far. Typically the video will work if the kernel has been given the correct vesa mode to show the system bootup messages. These are somewhat cryptic but they simple turn into an argument you append to the kernel boot parameters "vga=###".
I have buy an usb video grabber on ebay but I haven't received an official device, it's a fake, and this one is the only one fake not supported by Linux. I would like to write the linux driver, but I have no knowledge on driver dev. Where can I find tutorial for driver dev learning on linux?
The device is an easycap dc60++, identified as fushicai usbtv007. More details here : http://linuxtv.org/wiki/index.php/Easycap#Known_Easycap_devices
It works on win7, so I can easily sniff usb protocol.
Thanks you in advance
IMHO, the best way to learn how to develop drivers for the kernel is to take an existing driver (best if it's from mainline) that is similar to what you want and look at how they're doing it. For function references, head to your favourite LXR site and search it up.
You could look up Linux driver development on Google and find some tutorials but I wouldn't recommend it for anything other than to get started since they're likely to be outdated or use deprecated kernel APIs.
Otherwise, there's always libusb if you don't want to get into the world of kernel driver development.
Good luck.
I made an experimental userspace driver for this device:
https://github.com/memeruiz/usbtv007
Hopefully somebody (or me) will take this and make a proper kernel driver for it.
I've made a driver for the device in question (https://lkml.org/lkml/2013/6/10/381). There's a big space for improvement and I'd be very glad if you could get involved.
The following documentation is helpful:
Linux Device Driver, third edition, book.
PDFs: http://lwn.net/Kernel/LDD3/
epub: http://v3.sk/~lkundrak/ldd3/
Video4Linux2 API: http://lwn.net/Articles/203924/
Videobuf2 API: http://lwn.net/Articles/447435/
When it comes to a good example, have a look at the drivers/media/usb tree, particularly the stk1160 driver.
I didn't yet have a look at Federico Ruiz's libusb driver for the device, but it seems he mostly figured out the same things as I did about the hardware. I suggest you take a look at it though, as I'll certainly do.
Also, linux-media list is probably a better place to ask questions like this. I've got here mostly by accident and there certainly are much more capable people on the list.
Have a great day!
I have a Linux network driver that was originally written for 2.4 kernel. It works perfect.
I want to port it to kernel 2.6.31 and then to ARM Linux with same kernel i.e. 2.6.31. I have actually done some minor changes to the driver so that it is able to compile under kernel 2.6.31 and it also loads and unloads without crashing. It also cross compiles for the ARM Linux. But I am unable to test it on ARM so far.
How do I check that the driver is fully compatible with the target kernel, and what considerations shall be made to make it compatible with ARM.
The driver is a virtual network device driver.
Thanks in advance.
Maybe you could use Qemu ( http://wiki.qemu.org/Main_Page) to emulate an ARM platform to be able to test your driver.
You cannot check the driver like that - you have to consider the API changes within 2.6.x series kernel. The changes are quite significant and the overall of the API's from the 2.4 series which is not currently in use.
I would suggest you to go here to the Amazon book store for this book in particular. The book is called 'Essential Linux Device Drivers', by Sreekrishnan Venkateswaran. A very well detailed explanation that will be your guidance in ensuring it works properly.
Since you mentioned the device driver is a network, presumably char device (You're not accessing it in blocks), well, the good news is that the 2.6.x series kernel APIs for the character devices are significantly easier and more centralized to focus on - in fact a lot of the framework is already in place in which the author of said book explains very clearly.
By the way, the book focusses on the latter 2.6.x series after 2.6.19, so this will help you clue in on what needs to be done to ensure your driver works.
You did not specify the ARM chipset you're targetting?
As for testing... well.. perhaps the best way to do this, this is dependant on how you answer the above question to you regarding ARM chipset - if its ARMv6, then perhaps, a cheap android handset that you can easily unlock and root, and pop the kernel in there and see what happens - sorry for sounding contrived but that's the best thing I can think of and that's what pops into my head, to enable you to test it out for ease of testing :)
PS: A lot of cheap ARMv6 handsets would have kernel 2.6.32 running Froyo if that's of any help!