Questions about FKMS

[ali1234]

I'll get straight to the point:

1. Which kernel configuration options are required for FKMS?

2. How do I enable FKMS without using raspi-config?

3. How do I rotate the display when X isn't running?

4. Does FKMS work on every Pi model?

[6by9]

I'll get straight to the point:

1. Which kernel configuration options are required for FKMS?

To build it? It's part of DRM_VC4, which is enabled by default as a module in the defconfigs. See the Kconfig or make menuconfig options to work out the full list of dependencies.

2. How do I enable FKMS without using raspi-config?

https://github.com/RPi-Distro/raspi-con ... nfig#L1392
Basically add "dtoverlay=vc4-fkms-v3d" to /boot/config.txt. I thought at one point it disabled Plymouth (the splash screen) too.

3. How do I rotate the display when X isn't running?

This is one area where KMS does badly.
On vc4 (and others), rotation has to be done by composing the scene and transposing it as it writes it back to memory into another buffer. That second buffer then gets displayed to the live monitor.
DRM/KMS can expose this functionality via writeback connectors, but AFAIK there is no automatic config for telling a screen to simply be rotated.

NB X rotates using the 3D pipe rather than the transposer.

4. Does FKMS work on every Pi model?

Yes, although it'll be very slow on the 0/1, and you'll be very short of memory.

[ali1234]

Thanks, I'll give it a try.

I am not using X11 at all so how slow are we talking? I'll be running a Qt/QML EGLFS application and it is noticeably slower but still acceptable with the legacy drivers on a Pi Zero.

[gittubaba]

Kinda offtopic but what is the difference between vc4-fkms-v3d and vc4-kms-v3d?

[jamesh]

Kinda offtopic but what is the difference between vc4-fkms-v3d and vc4-kms-v3d?

FKMS (fake) uses the dispmanx and mailbox API's to talk to the firmware for things like the composition and video output stages.

KMS does all that by accessing the HW registers directly from ARM space, bypassing the firmware completely.

BUT this means that stuff still running on the firmware (camera code etc) does not work correctly as it has no idea that the ARM has pulled the rug out from underneath it.

So for the moment, FKMS is the best option.

[6by9]

Kinda offtopic but what is the difference between vc4-fkms-v3d and vc4-kms-v3d?

It's down to what actually drives the video scaler (HVS), pixel valves, and output display blocks (HDMI/VEC/DSI/DPI).
With vc4-fkms-v3d this remains with the firmware, and the firmware still allows DispmanX or MMAL to add extra layers.
With vc4-kms-v3d, the Linux kernel is driving all that lot, and DRM prohibits multiple clients adding layers at the same time.

There are fewer features now that you can't do with fkms, the main one being accurate timestamping (see get_vblank_timestamp in https://www.kernel.org/doc/html/latest/ ... rnals.html). Most other features can be implemented. If you find something missing then we'll do our best to accomodate it.
Adding a vc4-kms-v3d driver for Pi4 is still on the list of tasks, but mainly for completeness rather than an intent to switch to it by default any time soon.

[gittubaba]

Thank you both for the quick answer. I was having trouble with vga666 / DPI Display. dpi_ related entries in config.txt wasn't being applied. Landed here from google. Kinda off-topic, but problem is solved by switching to vc4-fkms-v3d from vc4-kms-v3d.

[6by9]

Thank you both for the quick answer. I was having trouble with vga666 / DPI Display. dpi_ related entries in config.txt wasn't being applied. Landed here from google. Kinda off-topic, but problem is solved by switching to vc4-fkms-v3d from vc4-kms-v3d.

vc4-kms-v3d doesn't understand any of the parameters that are available from config.txt - it changes the world view totally.

To add a DPI mode to vc4-kms-v3d you need to add a panel driver to device tree, or potentially enable the dpi peripheral in DT and add an additional mode to DRM/KMS using xrandr or similar.
There is an overlay for running a DPI display from vc4-kms-v3d as vc4-kms-kippah-7inch-overlay.dts that uses a panel driver to configure the Adafruit Kippah 800x480 DPI screen. That could be taken as a basis, but it gets a little involved.

Thinking about it, the other major area where vc4-kms-v3d has a benefit is that it would allow for any DSI panel to be connected, not just the RPi 7" one. Whilst it is requested quite a lot, that's not really a very common use case.

[gittubaba]

I see, the scenario becomes more clear now. I think this should be mentioned in https://www.raspberrypi.org/documentati ... /README.md . Just a note that "Instructions in this page won't work with vc4-kms-v3d"

There is an overlay for running a DPI display from vc4-kms-v3d as vc4-kms-kippah-7inch-overlay.dts that uses a panel driver to configure the Adafruit Kippah 800x480 DPI screen. That could be taken as a basis, but it gets a little involved.

What exactly is a "panel driver"? Is a driver written in c and need to be included when compiling kernel?
From your link i looked around and found this https://github.com/raspberrypi/linux/bl ... el-dpi.txt
Would making a overlay like this work? Desktop would show up in DPI? or there is more steps after applying overlay?

[6by9]

I see, the scenario becomes more clear now. I think this should be mentioned in https://www.raspberrypi.org/documentati ... /README.md . Just a note that "Instructions in this page won't work with vc4-kms-v3d"

Quite probably, although there are a fair few warnings around that the GL driver (vc4-kms-v3d) is still considered a beta driver and may require alternative options.

There is an overlay for running a DPI display from vc4-kms-v3d as vc4-kms-kippah-7inch-overlay.dts that uses a panel driver to configure the Adafruit Kippah 800x480 DPI screen. That could be taken as a basis, but it gets a little involved.

What exactly is a "panel driver"? Is a driver written in c and need to be included when compiling kernel?
From your link i looked around and found this https://github.com/raspberrypi/linux/bl ... el-dpi.txt
Would making a overlay like this work? Desktop would show up in DPI? or there is more steps after applying overlay?

So the panel driver is something like https://github.com/raspberrypi/linux/bl ... l-simple.c, and indeed that is the one that the Kippah overlay is loading. If you look at the overlay, it is saying the panel is a "ontat,yx700wv03". In the driver that string matches to
the configuration and timing structures ontat_yx700wv03, and that is how the peripheral will then be configured.

Checking on what implements your example overlay with a compatible string of "panel-dpi", it appears to be a TI omap specific driver - https://github.com/raspberrypi/linux/bl ... dpi.c#L258.
It looks like panel-lvds also uses the same of_get_display_timing() call to parse the timings out of device tree, but oddly panel-simple doesn't. I see no very good reason why it doesn't, so it would probably make sense to get it added at some point (how's your C coding?!)
At the moment things are too busy at Pi Towers for us to be looking at this, but we will be looking at vc4-kms-v3d for Pi4 relatively soon (hopefully a few months), so this may get combined into the scope of that.

[PeterO]

Quite probably, although there are a fair few warnings around that the GL driver (vc4-kms-v3d) is still considered a beta driver and may require alternative options.

Really ? My understanding of it was that since it is now the default setting it was considered "ready" ?
PeterO

[6by9]

Quite probably, although there are a fair few warnings around that the GL driver (vc4-kms-v3d) is still considered a beta driver and may require alternative options.

Really ? My understanding of it was that since it is now the default setting it was considered "ready" ?
PeterO

Note the lack of an "f".
fkms is adopted as standard on the Pi4.
kms doesn't exist on the Pi4, and requires configuration in significantly different ways.

[PeterO]

Quite probably, although there are a fair few warnings around that the GL driver (vc4-kms-v3d) is still considered a beta driver and may require alternative options.

Really ? My understanding of it was that since it is now the default setting it was considered "ready" ?
PeterO

Note the lack of an "f".
fkms is adopted as standard on the Pi4.
kms doesn't exist on the Pi4, and requires configuration in significantly different ways.

So despite asking for a clear description of all this the other day it is clear that I'm still confused about it
PeterO

[fruitoftheloom]

Really ? My understanding of it was that since it is now the default setting it was considered "ready" ?
PeterO

Note the lack of an "f".
fkms is adopted as standard on the Pi4.
kms doesn't exist on the Pi4, and requires configuration in significantly different ways.

So despite asking for a clear description of all this the other day it is clear that I'm still confused about it
PeterO

Yes I am confused as well, but I believe I should be running fakeKMS on all RPis

[gittubaba]

So the panel driver is something like https://github.com/raspberrypi/linux/bl ... l-simple.c, and indeed that is the one that the Kippah overlay is loading. If you look at the overlay, it is saying the panel is a "ontat,yx700wv03". In the driver that string matches to
the configuration and timing structures ontat_yx700wv03, and that is how the peripheral will then be configured.

Checking on what implements your example overlay with a compatible string of "panel-dpi", it appears to be a TI omap specific driver - https://github.com/raspberrypi/linux/bl ... dpi.c#L258.
It looks like panel-lvds also uses the same of_get_display_timing() call to parse the timings out of device tree, but oddly panel-simple doesn't. I see no very good reason why it doesn't, so it would probably make sense to get it added at some point (how's your C coding?!)

I see, the name "panel" implies a touchscreen What I wanted was a simple vga666 output. I'll mess with those drivers and overlays and see what i can do

[fruitoftheloom]

So the panel driver is something like https://github.com/raspberrypi/linux/bl ... l-simple.c, and indeed that is the one that the Kippah overlay is loading. If you look at the overlay, it is saying the panel is a "ontat,yx700wv03". In the driver that string matches to
the configuration and timing structures ontat_yx700wv03, and that is how the peripheral will then be configured.

Checking on what implements your example overlay with a compatible string of "panel-dpi", it appears to be a TI omap specific driver - https://github.com/raspberrypi/linux/bl ... dpi.c#L258.
It looks like panel-lvds also uses the same of_get_display_timing() call to parse the timings out of device tree, but oddly panel-simple doesn't. I see no very good reason why it doesn't, so it would probably make sense to get it added at some point (how's your C coding?!)

I see, the name "panel" implies a touchscreen What I wanted was a simple vga666 output. I'll mess with those drivers and overlays and see what i can do

"Panel" is via the DSi Connector in this context, nothing to do with VGA, which already has a solution:

https://uk.pi-supply.com/products/gert- ... spberry-pi

[6by9]

I see, the name "panel" implies a touchscreen What I wanted was a simple vga666 output. I'll mess with those drivers and overlays and see what i can do

Panel implies a display panel.
Touchscreen overlays on the front of a panel would be a separate input driver - https://github.com/raspberrypi/linux/tr ... ouchscreen

I see, the name "panel" implies a touchscreen What I wanted was a simple vga666 output. I'll mess with those drivers and overlays and see what i can do

"Panel" is via the DSi Connector in this context, nothing to do with VGA, which already has a solution:

https://uk.pi-supply.com/products/gert- ... spberry-pi

Er, fruit, display panels can be DSI, DPI, LVDS, or a number of other interfaces. They all have very similar timing information requirements.
The VGA666 looks like a DPI display panel as far as the Pi is concerned. It simply uses a resistor ladder as a crude DAC.

[gittubaba]

"Panel" is via the DSi Connector in this context, nothing to do with VGA, which already has a solution:

https://uk.pi-supply.com/products/gert- ... spberry-pi

No my friend, you missed the context That vga666 adapter needs DPI, and DPI is what we were discussing.

[fruitoftheloom]

"Panel" is via the DSi Connector in this context, nothing to do with VGA, which already has a solution:

https://uk.pi-supply.com/products/gert- ... spberry-pi

No my friend, you missed the context That vga666 adapter needs DPI, and DPI is what we were discussing.

Yes have been made aware by the Mod.

[gittubaba]

Okey first I wasted couple of hours bcz I had CONFIG_DRM_PANEL_SIMPLE disabled in my kernel .config
I can enable DPI and control its timing/freq/res by editing drivers/gpu/drm/panel/panel-simple.c and recompiling kernel.
The problem is now how to do what display_default_lcd=1 did. I want to disable hdmi and make DPI display default. Not sure how to do that now

Edit: Update:
Whlie with xrandr i can disable hdmi and make DPI primary, i was looking for a solution more from kernel side (If that makes any sense). By experimenting with DT overlays, i found out vc4-kms-v3d-overlay was enabling hdmi, so I applied this in my overlay,

Code: Select all

	fragment@3 {
		target = <&hdmi>;
		__overlay__  {
			status = "disabled";
		};
	};

This seems to be working and disabling hdmi. xrandr don't even detect hdmi and DPI becomes default display