Custom KMS driver + X

[Adam Jackson]

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.

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.

- ajax