thread 'main' panicked at 'Could not set CRTC: InvalidArgument' in Examples/legacy_modeset.rs about drm-rs HOT 13 CLOSED

This is unfortunately not that easy to debug, because that error comes directly from the kernel.

wlroots has a pretty good docs on how to enable drm logs from the kernel:
https://github.com/swaywm/wlroots/wiki/DRM-Debugging

You should try to get a log this way and run your executable instead of sway or any real compositor in between.

Also it might be helpful to know little more about your system. Especially what kind of graphics card you are using and which driver, that might give us a clue, whats going wrong here.

from drm-rs.

If possible, you can try running the kms_interactive example and then run "GetResources" to see what sort of connectors, CRTCs, and framebuffers you have available.

from drm-rs.

@Drakulix I've tried it on real hardware, where it works as expected. My laptop is a Dell Inspiron 15 7570, with an onboard Intel GPU (UHD Graphics 620) and the i915 kernel module. My dedicated card is an NVidia GeForce mx130 (GM108M), although it looks like this card isn't used extensively, as my system information panel tells me it's using the Intel card on the Mesa drivers.

As for my testing environment, that's a simple Qemu VM, using the Virtio GPU. I'm not sure how to change that to be honest.

from drm-rs.

So I was able to reproduce this on an Arch Linux VM running virtio GPU drivers. The same issue does not occur on QXL oddly enough, which is the driver I originally developed the examples in. Running this with DRM debugging turned on results in the following in the kernel output:

[  220.534692] [drm:drm_ioctl] comm="legacy_modeset" pid=496, dev=0xe200, auth=1, DRM_IOCTL_MODE_ADDFB
[  220.534697] [drm:drm_mode_addfb2] [FB:39]
[  220.534748] [drm:drm_ioctl] comm="legacy_modeset" pid=496, dev=0xe200, auth=1, DRM_IOCTL_MODE_SETCRTC
[  220.534751] [drm:drm_mode_setcrtc] [CRTC:33:crtc-0]
[  220.534754] [drm:drm_mode_setcrtc] Invalid pixel format AR24 little-endian (0x34325241), modifier 0x0
[  220.534756] [drm:drm_mode_object_put.part.0] OBJ ID: 39 (2)
[  220.534758] [drm:drm_ioctl] comm="legacy_modeset", pid=496, ret=-22
[  220.534795] [drm:drm_release] open_count = 1
[  220.534797] [drm:drm_file_free.part.0] comm="legacy_modeset", pid=496, dev=0xe200, open_count=1
[  220.534799] [drm:drm_mode_object_put.part.0] OBJ ID: 39 (1)
[  220.534811] [drm:_drm_lease_revoke] revoke leases for 00000000442c7caf 0
[  220.534813] [drm:drm_lease_destroy] drm_lease_destroy 0
[  220.534814] [drm:drm_master_destroy] drm_lease_destroy done 0
[  220.534815] [drm:drm_release]
[  220.534816] [drm:drm_release] driver lastclose completed

The issue is the Invalid pixel format AR24 little-endian (0x34325241), modifier 0x0 part, where we appear to be trying to use AR24 pixel format for our framebuffer, which I guess is not a supported pixel format in virtio.

What confuses me on this, is we are actually trying to use Rgba8888 for the dumbbuffer, which is definitely in the code here:

// Select the pixel format
let fmt = DrmFourcc::Rgba8888;

// Create a DB
// If buffer resolution is larger than display resolution, an ENOSPC (not enough video memory)
// error may occur
let mut db = card
    .create_dumb_buffer((disp_width.into(), disp_height.into()), fmt, 32)
    .expect("Could not create dumb buffer");

But when we pretty print it further down, the output is this:

DumbBuffer {
    size: (
        1024,
        768,
    ),
    length: 3145728,
    format: DrmFourcc(
        RA24,
    ),
    pitch: 4096,
    handle: buffer::Handle(
        1,
    ),
}

It is set to RA24 for some reason. This format is the same on virtio, QXL, and real hardware. I think this needs a closer look to figure out why this is happening.

from drm-rs.

I have no idea how DrmFourcc implements display and why it prints it as RA24, but I did find the 2 issues for why this isn't working on virtio

1. The virtio GPU driver only seems to support XRGB8888 for framebuffers, and ARGB8888 for cursor planes.
2. For a framebuffer that's being directly displayed to the screen, the alpha channel is not used and the depth should be 24 instead of 32. Other drivers appear to ignore this, but virtio throws an error and refuses to use it.

It would be best to try and determine which pixel format to use based on the system, but for this example I think we can just change it. Unless someone is using a transparent display where the alpha channel is actually used, XRGB8888 seems like a sane default for an example.

from drm-rs.

@J-Cake - Can you try the fix in #111 and ensure it works on your system?

from drm-rs.

@Slabity Thanks so much for your help. I'm not entirely sure how to run against a specific commit, so I've tried my best: My Cargo.toml file:

...
[dependencies]
drm = { git = "https://github.com/Slabity/drm-rs/", rev = "3818829" }
...

Did a cargo update ; cargo build, ran it and got the same error unfortunately. I did have to go through a huge glibc upgrade process, but that went smoothly.

As for your previous request regarding the kms_interactive script, here is its output.

KMS>> GetResources
        Connectors: [connector::Handle(34)]
        Encoders: [encoder::Handle(35)]
        CRTCS: [crtc::Handle(33)]
        Framebuffers: [framebuffer::Handle(41), framebuffer::Handle(42), framebuffer::Handle(40), framebuffer::Handle(39)]
        Planes: [plane::Handle(31), plane::Handle(32)]
KMS>> 

Edit: I reran the example under #111 and as far as I can tell, I get the same result.

KMS>> GetResources
        Connectors: [connector::Handle(34)]
        Encoders: [encoder::Handle(35)]
        CRTCS: [crtc::Handle(33)]
        Framebuffers: [framebuffer::Handle(43), framebuffer::Handle(39), framebuffer::Handle(41), framebuffer::Handle(40)]
        Planes: [plane::Handle(31), plane::Handle(32)]
KMS>> 

from drm-rs.

@J-Cake - You should be able to just clone the repo from my branch directly and run the example like so:

$ git clone https://github.com/Slabity/drm-rs
$ cd drm-rs
$ cargo run --example legacy_modeset

Ensure the fmt variable is DrmFourcc::Xrgb8888 and the add_framebuffer command has a 24 for the depth instead of 32

If you get the error still, do the following:

$ echo 0x19F | sudo tee /sys/module/drm/parameters/debug
$ cargo run --example legacy_modeset
$ sudo dmesg | grep drm_mode_setcrtc

And post the output of the final command here.

from drm-rs.

So I ran the legacy_modeset.rs example on my virtual machine, and got a grey screen, indicating that it's worked.

It also prints the expected output:

Mode {
    name: "1920x1026",
    clock: 206250,
    size: (
        1920,
        1026,
    ),
    hsync: (
        2400,
        2457,
        2592,
    ),
    vsync: (
        1031,
        1036,
        1061,
    ),
    hskew: 0,
    vscan: 0,
    vrefresh: 75,
    mode_type: PREFERRED | DRIVER,
}
framebuffer::Handle(
    40,
)
DumbBuffer {
    size: (
        1920,
        1026,
    ),
    length: 7880704,
    format: DrmFourcc(
        XR24,
    ),
    pitch: 7680,
    handle: buffer::Handle(
        1,
    ),
}

Edit: I checked out to f48d9c1c9b5af2d9895ff1c118a9c75eafc4f8f2 and reran the example, and it didn't work. It looks like your changes fixed things.

from drm-rs.

So I ran the legacy_modeset.rs example on my virtual machine, and got a grey screen, indicating that it's worked.

Excellent! That should be the expected behavior. The issue is that the examples were using a pixel format that the virtio GPU drivers didn't support for direct output.

@Drakulix - Could you do a quick sanity check of the changes and merge? It's a pretty tiny change.

from drm-rs.

Thanks a billion again for your help. There have been countless examples of developers not responding to queries like these, so I'm really happy to see that issue was resolved as quickly as it was.

Next question: What would the best way of detecting the most appropriate format be?

from drm-rs.

Honestly I'm not certain what the best method of that would be.

I know that planes will list their supported pixel formats, which you can get by using plan::Handle::formats and then DrmFourcc::from_u32 on the result. Unfortunately, legacy modesetting doesn't really have a concept of planes.

That said, unless you are targeting a kernel version from before 2015, I highly recommend using atomic modesetting. There's not really any reason not to unless you need to support a version of the linux kernel that doesn't support it. In fact, legacy modesetting functions in the kernel are typically implemented on top of atomic modesetting nowadays.

from drm-rs.

Ah no problem. I'll see what I can do with that. Thanks again for all your help.

from drm-rs.