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
Related
Helo All,
I am trying to learn embedded linux.
Please provide clarity on below:
As DTB provides Board and SOC related information will it be sufficient to make sure correct drivers will be enabled?
How a correct driver will get selected and will it happen during build time or kernel runtime based on the DTB?
How are drivers for platform devices(UART, SPI, I2C etc) handled in Linux? I mean as different SOC's have different implementations(register and bit fields will be different) of these peripherals how a single driver will be able to handle both SOC's?
Is it sufficient to have well defined DTB about board and kernel to make Linux up and running on any platform.
Thanks,
Suraj
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 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 been studying linux driver recently,
as those articles I read said, the device driver modules are likely to be automatically loaded on demand by kernel, I am therefore wondering about the recipe how kernel figures out which module to load for a specific device(sound card, I2C/spi device, etc), I also cannot thoroughly imagine how the kernel detects each hardware device while boot-time .
answers relevant to embedded linux are prefered , PC linux are also welcome !
3Q
I think you are mixing two different things, which is hardware detection, and on demand module loading.
In some cases, the kernel is explicitely doing a module request. However, in most cases, the kernel itself does not do any "on demand loading".
But wait, you must be mistaken, if I plug my shiny new webcam, isn't
the module automagically loaded ?
Yes it is, but not by the kernel. All the kernel does is calling a userspace program with so called "hotplug event" or "uevent" as arguments. On Linux PC, this userspace program is usually udev, but on embedded system, you can use for example mdev. You can find a more detailed explanation here and here
Regarding the second part of your question, the kernel is doing hardware discovery only if the hardware is discoverable. Example of discoverable hardware is USB and PCI. Example of non discoverable harwdare busses is SPI or I2C.
In the latter cases, the presence of a particular device on a given bus is either encoded directly in the kernel, or given to him by the booloader. Google for "device tree" for an example of the latter.
To sum things up : Hardware detection is done by the kernel, and module loading is done by userspace, with information provided by the kernel.
What tools are available to monitor graphics card memory usage in linux?
NVIDIA PerfKit has a linux version which allows real-time monitoring of various graphics card properties, including graphics card memory usage. Obviously, this only works for NVIDIA graphics cards, and it also requires the use of a special instrumented driver.
If you just need to know it for 3D graphics development purposes, you may want to look into something like gDEBugger or, if you only care about NVIDIA cards, you can try NVIDIA PerfHUD. I have not used them myself, but I would expect them to track such information.