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=###".
Related
I may have a couple assumptions of Linux incorrect about the Linux system, and for that I apologize.
I have been educating myself on the Android and Linux systems for a while now and I started looking into installing a custom boot loader and Linux system onto an older Samsung tablet. Immediately upon looking into the feasibility of this, most of the answers I could find were that it wasn't possible because you would need the drivers that are being used by the android kernel to communicate with the OEM hardware in whatever Linux kernel you are installing.
I have one of these tablets rooted and I believe I may have found the drivers I need (not sure on that yet), and so I guess my question is, is it possible to take the drivers and put them into a Linux kernel within a distribution install image and install Linux on the device (using also a custom boot loader)?
I presume because someone hasn't done this before there is a pretty good reason why, but I am basically looking to be able to use Linux on my old tablet without the resources being taken from Android, and personally in my opinion, if I don't need Android and can install Linux straight on to the machine, then why keep it?
In the long run I am looking into LFS to create a custom distribution that can be installed on these tablets, but the most important question to me right now is if I do create this distribution can I get the drivers that the hardware needs (and even then will my kernel be able to use them?).
I also understand that some of these drivers may be proprietary drivers provided by the manufacturer, but I am not looking to profit off of this but instead research the feasibility of a better personal on-the-go computing setup.
I may be terribly wrong on how I may have described some things, so here are some of my assumptions:
The .ko files in the Android /lib/modules/ directory are the static kernel drivers I am looking for for that device.
The drivers aren't written for specifically the Android system, but for all Linux variants and would be compatible with another distribution.
If the drivers were written for the Android system, then one would be able to edit or modify those drivers to work with a different distribution.
One could "put the drivers into an installation image", or if not, then one would have to compile the kernel from source with those static drivers.
TL:DR, If this all just amounts to rambling, here are my specific questions:
Is it possible to copy the static kernel drivers of a rooted Android device to something like the SDcard?
Is it then possible to "put" or "compile" those same static drivers into a Linux distribution before installing it onto said tablet using something like Odin, or the like?
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 am new to linux kernel debugging. I have a radeon graphics card and I am doing some graphics driver development for my embedded system. Before making a custom driver for another radeon card, I want to know how the graphics driver behaves in linux. I have studied a bit on DRM, GEM/TTM, KMS, Framebuffers; but I want to see them actually happening on linux systems. I have Ubuntu system with kernel 3.10.x
I want to debug the driver and see the following. Please help how to do it.
How to access framebuffer and see what is currently being drawn. (This is more of a curiosity)
Wish to see how TTM and GART tables are maintained and interpret them(any link would also help) and KMS as my display is DVI-D
How DMA is playing role here. Can I begin without DMA (over PCI for time being etc..)
Minimal device driver requirement to draw some raw pixels on screen
Unlike linux, devices in my embedded system are not treated as files. So need to understand them and reinterpret them for my system.
Plan is to make Mesa over it. Just I am in the beginning stage. So any help would be appreciated.
Thanks
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.
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!