allow specifying the mode in the command line

[sgerwk]

With this change, the output from "cvt x y clock" can be used as parameters for modeset.c. This allows for modes that are not among the modes of a connector. For example, 800x400 can be be used even if it is not one of the modes of the active connectors:

modeset $(cvt 800 400 75 | grep -v '^#')

Of course, this may fail if not supported by the hardware.

Two other changes are made necessary by this:

1. instead of 'modeset /dev/dri/card0', this parameter now requires -d, as otherwise the program would not be able to tell this from the name of the mode

2. filling the screen with the same color hides the difference in resolution; this is now enphasized by a small black 10x10 square at position 100,100

[sgerwk]

The modeset.c is a great example for understanding how drm works. It allows for getting the main points of drm quickly and in a practical way. The only point of it that I found a bit misleading is that somehow it seems to imply that the only modes that can be used are those found in the list of modes for a connect (at least, I got this impression). This PR should clarify that this is not necessary, as an arbitrary mode can be passed from the command line; it may then be supported or not by the hardware.

[dvdhrm]

I don't think this belongs into the modeset.c introduction. I agree that this is definitely worth mentioning, but I think this should rather be separate.

There are many things this introduction does not cover. One day, I would love to convert them to atomic-modesetting. However, I believe the best way to do that is to redo the entire series. DRM has evolved over time, and there are many things you can do better now.

The purpose of this series was to give an introduction into DRM. I think it serves it well. Anyone understanding the code, should be ready to dive into the the kernel's ioctl definitions. This series is not a replacement for DRM documentation.

I will leave this PR open, for documentational purposes. Maybe this way people can find the code.

Thanks!

[sgerwk]

Sure, I understand.

Still: thanks for writing this tutorial, it's very clear.

[magiblot]

Excuse me for the bump, but I believe what I want to ask is more related to this pull request than to the original drm-helper.

Would it be possible to set the video mode and then, instead of seeing a black screen (or calling modeset_draw), continue working with the console (tty)?

It appears to be that many *drmfb drivers (e.g. inteldrmfb) have an incomplete support for fbdev and the classic tool for framebuffer modesetting (fbset) does not work anymore. So I thought the issue should be treated from low-level and after some research I found dvdhrm's WordPress and drm-helper.

Thank you very much.

[sgerwk]

I tried this myself, and come up to the conclusion that this is not possible: the console driver in the kernel only runs on fbdev (the mode can be changed by e.g., the video= kernel option, but does not look to be changeable at run-time). For drm, you need a user-space terminal emulator program that is able to change mode and then draw the characters itself in drm, such as kmscon.

[magiblot]

The fbset command does not change the video mode but can confine the active part of the display in the top-left corner. For example, with the following command, and provided that the actual resolution is greater than the one we are asking for: fbset -g 640 480 640 480 32 Applications will use only a 640x480 section in the top-left part of the screen, and the rest of the framebuffer will remain unchanged.

Would it be possible to copy that part of the framebuffer to drm and display the 640x480 region in full-screen, with the proper video mode?

In case it is, and if it's as simple as it sounds, the overhead could be compensated with SIMD instructions that copy several bytes at a time.