Hi Adam, Thanks for your answer!
On 06-07-2016 15:57, Adam Jackson wrote: > On Tue, 2016-07-05 at 15:28 +0100, Jose Abreu wrote: > >> - First: My driver only supports 24 bpp (I mean real 24 >> bits, not 24 packed in 32 bits). Is there a way to specify to X >> (or specify in the driver itself) to use 24bpp **only** in the >> new driver that I created? > Kind of. The arguments to xf86SetDepthBpp (which you're probably > calling in your PreInit hook) specify how the root window is to be > treated. If you can only do 24bpp, you'll want to pass Support24bppFb > (and nothing else) as the last argument. By default (ie, without exa or > glamor or other acceleration) other pixmaps will be created in host > memory as 32bpp, and the software renderer will convert between formats > as needed. If you want to add support for pixmaps in video memory > you'll need to enforce the 24bpp restriction in your accel support > code. Ok, something is missing because I am not calling xf86SetDetpthBpp at all. You mean I need to have a X driver (or module, I don't know the nomenclature) in order to use my KMS driver? Can't I just use the 'modesetting' driver? Sorry if I am making some dumb mistake but my understanding of the inner workings of X is barely null. Right now I am able to force X to use 24bpp in the KMS driver. I just return -EINVAL in the dumb_create() callback of DRM when the bpp is not 24 and then X tries again with the right bpp, but when I do this the X stops working and in the log it appears the stack trace that I sent in the first email. > > That said, a lot of client software these days gets so confused by > 24bpp that we've added code to the stock modesetting driver to maintain > a 32bpp shadow framebuffer in host memory, and convert at screen update > time: > > https://cgit.freedesktop.org/xorg/xserver/commit/?id=21217d02168d1883b2d1f64399aec494f96a8b9d > > If you can possibly support 32bpp instead I recommend it. If you can't > but aren't doing any hardware accel, the 32→24 conversion approach > above is probably best. If you really do want 24bpp with hardware > accel, well, have fun. > >> - Second (and most important one): If I start my workstation >> and modprobe the driver the X server seems to recognize and add >> the new DRM device (I can't be sure because right now no output >> is shown due to the 24/32 bpp problem). But if I then do a >> "startx" from terminal the server will crash with a segmentation >> fault, outputting this log: >> >> [snip...] >> (II) xfree86: Adding drm device (/dev/dri/card1) >> (EE) >> (EE) Backtrace: >> (EE) 0: /usr/bin/X (xorg_backtrace+0x48) [0x7f7e3c6f5fc8] >> (EE) 1: /usr/bin/X (0x7f7e3c555000+0x1a4ff9) [0x7f7e3c6f9ff9] >> (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (0x7f7e3a6d5000+0x36cb0) >> [0x7f7e3a70bcb0] >> (EE) 3: /usr/bin/X (0x7f7e3c555000+0xb3539) [0x7f7e3c608539] >> (EE) 4: /usr/bin/X (xf86BusProbe+0x9) [0x7f7e3c5dc1e9] >> (EE) 5: /usr/bin/X (InitOutput+0x728) [0x7f7e3c5ea668] >> (EE) 6: /usr/bin/X (0x7f7e3c555000+0x57dab) [0x7f7e3c5acdab] >> (EE) 7: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf5) >> [0x7f7e3a6f6f45] >> (EE) 8: /usr/bin/X (0x7f7e3c555000+0x4352e) [0x7f7e3c59852e] >> (EE) >> (EE) Segmentation fault at address 0x0 >> (EE) >> Fatal server error: >> (EE) Caught signal 11 (Segmentation fault). Server aborting >> (EE) >> >> <snip> >> >> Can you give me any comments regarding these two problems? > It looks like that crash is happening way before any driver gets > loaded, so I'm not really sure what's going on there. I'd need to know > exactly how X was getting invoked by startx and which OS's build of the > X server you were using to figure out more. > > startx isn't really the tool you want to use to debug just starting the > X server though, it tries to bring up a session as well. If you can ssh > in from another machine and start X directly from gdb your debugging > life will be much more pleasant. Just for reference: Running OS: Ubuntu 15.04 X Server: 1.17.1 X Built Operating System: Linux 3.19.0-28-generic X86_64 Ubuntu Running Kernel: 3.18.29 > > - ajax Best regards, Jose Miguel Abreu _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
