backend-drm: Get optional WESTON_TRANSFORM from udev.

Should allow configuration of rotation along the lines of:

ACTION!="remove", SUBSYSTEM=="drm", SUBSYSTEMS=="pci|usb|platform", KERNEL=="card*", ENV{WL_OUTPUT}="VGA-1", ENV{WESTON_TRANSFORM}="rotate-270"

added 1 commit

• bc53c836 - backend-drm: Get optional WL_TRANSFORM from udev.

Compare with previous version

Can we avoid using the WL_ prefix? I'd prefer WESTON_ to make it clear this isn't something that'll work on all Wayland compositors.

Yep, changed it to WESTON_TRANSFORM.

FYI I left WL_OUTPUT as is since that should match the same format as libinput uses for udev output configuration, do you think it makes sense to leave that or should I prefix it with WESTON_ as well?

Yeah, changing it would break existing setups I'm afraid. Note, libinput doesn't do anything with WL_OUTPUT apart from exposing a deprecated getter in its API. Also, WL_OUTPUT is ill-defined.

Ok, I'll leave that part as is then.

added 1 commit

• 13be7601 - backend-drm: Get optional WESTON_TRANSFORM from udev.

Compare with previous version

changed title from backend-drm: Get optional WL_TRANSFORM from udev. to backend-drm: Get optional WESTON_TRANSFORM from udev.

changed the description

Btw. setting WL_OUTPUT on a DRM device makes no sense. Libinput is the precedent for using WL_OUTPUT, and it won't look at DRM devices. Assigning a DRM card node to a specific output for input event mapping simply does not compute.

It seems like you are re-purposing WL_OUTPUT to something totally different, and the scheme also cannot handle the same DRM device exposing multiple outputs.

The biggest question is though:

Why do you want to configure this in weston-specific udev rules instead of in weston.ini?

Btw. setting WL_OUTPUT on a DRM device makes no sense.

Well I'm not really setting WL_OUTPUT on the device so much as using it to filter outputs in which to apply the WESTON_TRANSFORM.

It seems like you are re-purposing WL_OUTPUT to something totally different, and the scheme also cannot handle the same DRM device exposing multiple outputs.

I think it should work with fine with multiple outputs, it's specifically designed for enabling proper transform handling of multi-output hardware, if you omit WL_OUTPUT it applies the transform to all outputs, otherwise it filters which outputs get rotated based on WL_OUTPUT being present so that you can apply a transform conditionally only to one output if needed.

Why do you want to configure this in weston-specific udev rules instead of in weston.ini?

I need to be able to apply transform rules with effectively with arbitrary conditions, for example I may use the same exact firmware build for hundreds of machines with different screen orientations, this way I can use some sort of udev match rule(matching based on a board serial number or board model for example) to apply rotation correctly to the ones that need it using udev.

@jameshilliard Regarding your use case and that you are working with a DRM backend, can you not use the DRM panel orientation property? There's probably a good reason but I would be curious to hear why this is not sufficient to meet your needs. Support for using the DRM panel orientation property was added here: !315 (merged)

Regarding your use case and that you are working with a DRM backend, can you not use the DRM panel orientation property?

From my understanding that would not cover my use case of dynamically setting the orientation in cases where the driver does not(and likely can not) provide accurate orientation info as in !315 (merged)(which I used as a reference for this implementation) where it's indicated that:

This property allows a KMS driver to statically declare a fixed orientation for a connector. This is useful in cases such as mobile phones or embedded displays which can have displays mounted at an unexpected orientation.

In my use case the orientation is not fixed by connector but can depend on many other system variables, in some cases I have to have udev rules match against somewhat arbitrary unique board values like ethernet adapter mac addresses(in cases where unique board serial numbers or other unique variables are not available) as we have hardware being manufactured which uses the same motherboard model but different screen mounting orientations. We also have to support in field hardware that we don't have the ability to meaningfully customize. Using udev for this rotation configuration appears to provide sufficient flexibility to allow for the use of unified firmware images across these many different embedded systems we support.

Well I'm not really setting WL_OUTPUT on the device so much as using it to filter outputs in which to apply the WESTON_TRANSFORM.

But you are setting it. That is what the udev rule does.

I suppose by filtering you refer to the code you add in Weston, but that is re-purposing WL_OUTPUT to something it's not. I have a big problem with re-purposing WL_OUTPUT: it's a huge surprise that an attribute on one device would mean something totally different than on another device, depending on what kind of device it is.

I think it should work with fine with multiple outputs, it's specifically designed for enabling proper transform handling of multi-output hardware, if you omit WL_OUTPUT it applies the transform to all outputs, otherwise it filters which outputs get rotated based on WL_OUTPUT being present so that you can apply a transform conditionally only to one output if needed.

How do you configure on the same card output VGA-1 to rotate-90 and HDMI-2 to flipped, for instance?

I need to be able to apply transform rules with effectively with arbitrary conditions, for example I may use the same exact firmware build for hundreds of machines with different screen orientations, this way I can use some sort of udev match rule(matching based on a board serial number or board model for example) to apply rotation correctly to the ones that need it using udev.

I see. Did you think about generating a correct weston.ini on start-up before choosing to go the udev rule way? What is your rationale to prefer udev rules?

A custom script or program would not be limited to what udev rules can match against. Are you sure you actually can match against everything you need with udev rules? You mentioned potentially matching against characteristics of network devices or anything else, and I'm not sure you can refer to arbitrary other device characteristics from udev rules. Besides, what is going to guarantee the unrelated device is going be already initialized at the time this udev rule is running?

Is it really enough to stop at rotation only? Are you sure there is no way you might ever want to configure e.g. the video mode, refresh rate, force an output off, or in the future set a specific color profile and HDR mode?

Even if you are sure there will never be any other needs than rotation, can we assume so in Weston upstream? I think not. I also think it is not nice to add this kind of single-purpose inflexible features to Weston in upstream, especially when there is a clear alternative solution that to me seems strictly superior: generating a weston.ini before starting Weston.

OTOH, if you did have a program that generates a weston.ini, then if you e.g. use systemd as PID 1, you can make that a separate one-shot service and have guarantees that all the needed arbitrary devices you want to look at have been probed and initialized before the program runs, and you can guarantee Weston is not started before there is a weston.ini.

Is there something else I should consider?

I suppose by filtering you refer to the code you add in Weston, but that is re-purposing WL_OUTPUT to something it's not. I have a big problem with re-purposing WL_OUTPUT: it's a huge surprise that an attribute on one device would mean something totally different than on another device, depending on what kind of device it is.

Maybe I should rename it to WESTON_OUTPUT?

How do you configure on the same card output VGA-1 to rotate-90 and HDMI-2 to flipped, for instance?

Hmm, I was assuming that could be done by using two udev rule...one for each output...but I could be wrong...I guess I should try and test that sort of scenario.

I see. Did you think about generating a correct weston.ini on start-up before choosing to go the udev rule way? What is your rationale to prefer udev rules?

It didn't seem particularly reliable to dynamically generate weston.ini. I use udev rules for most of my runtime auto-configuration already, such as mapping serial devices/ports, it seemed best to use something similar for runtime auto-configuration of weston.

Are you sure you actually can match against everything you need with udev rules?

Haven't run across any situations that I couldn't make work so far.

You mentioned potentially matching against characteristics of network devices or anything else, and I'm not sure you can refer to arbitrary other device characteristics from udev rules.

Seems to work fine, here's one I use for a serial device for example:

SUBSYSTEM=="tty", ATTR{[dmi/id]board_vendor}=="INTEL Corporation", ATTR{[dmi/id]board_name}=="MAHOBAY", ATTR{[net/enp2s0]address}=="00:e0:67:25:ff:cc", ATTR{port}=="0x3E8", SYMLINK+="ledserial"

Besides, what is going to guarantee the unrelated device is going be already initialized at the time this udev rule is running?

I haven't run into issues there...might be because I build the ethernet network drivers I need into the kernel.

Is it really enough to stop at rotation only? Are you sure there is no way you might ever want to configure e.g. the video mode, refresh rate, force an output off, or in the future set a specific color profile and HDR mode?

I mean, we could add more I suppose, but this seems like it's the most important one to have dynamic configuration capability for as static configuration seems likely to be sufficient in most cases for those other configs.

OTOH, if you did have a program that generates a weston.ini, then if you e.g. use systemd as PID 1, you can make that a separate one-shot service and have guarantees that all the needed arbitrary devices you want to look at have been probed and initialized before the program runs, and you can guarantee Weston is not started before there is a weston.ini.

Hmm, I tend to avoid dynamic config file generation entirely, I guess that technique just seems brittle/unreliable to me.

Hmm, I was assuming that could be done by using two udev rule...one for each output...but I could be wrong...I guess I should try and test that sort of scenario.

Whatever udev rules run, the end result is always at most a single value for a property. So at the very least your Weston code cannot handle multiple outputs configured like this.

I haven't run into issues there...might be because I build the ethernet network drivers I need into the kernel.

Sounds fragile. It still depends on driver initialization order vs. sending uevents from the kernel and udevd handling those. Drivers are expected to initialize in parallel, even those built-in AFAIU.

Hmm, I tend to avoid dynamic config file generation entirely, I guess that technique just seems brittle/unreliable to me.

I find that a funny statement, given I believe you are depending on luck with the udev rules accessing unrelated device information.

Udev rules get executed every time the kernel sends an uevent on that particular device, regardless of anything else. There is zero dependency management. Systemd services OTOH have well-established and guaranteed dependency management and failure handling. Generating a weston.ini on boot into tmpfs is really what I'd do.

Whatever udev rules run, the end result is always at most a single value for a property. So at the very least your Weston code cannot handle multiple outputs configured like this.

So it would need to be maybe something like this for correct multiple output handling?:

ENV{WESTON_TRANSFORM}="VGA-1:rotate-270,HDMI-2:flipped"

Sounds fragile. It still depends on driver initialization order vs. sending uevents from the kernel and udevd handling those. Drivers are expected to initialize in parallel, even those built-in AFAIU.

Hmm, what would be the correct way to make this hot-pluggable so that the rotation would say get applied even if weston is already running when a udev event arrives?

I find that a funny statement, given I believe you are depending on luck with the udev rules accessing unrelated device information.

I do generally try to avoid matching network device mac's, like say for USB FTDI devices I'll just match the FTDI USB serial numbers directly, but I've ended up having to support a bunch of random industrial boards where they aren't setting any other unique attributes for whatever reason.

what would be the correct way to make this hot-pluggable so that the rotation would say get applied even if weston is already running when a udev event arrives?

Generate the correct weston.ini before launching Weston.

When Weston notices monitor hotplug, it will match the connector to weston.ini and use that configuration. A problem here is that if you expect to be hotplugging different monitors in the same connector and need different settings for them, that is something Weston simply does not support right now, but it would be a welcome feature I think: to match [output] sections by monitor make/model/serial rather than just DRM connector name. However, if your use case does not include swapping monitors in flight then this is not a concern at all. You just generate the weston.ini differently on start-up based on whatever you want.

Unless you force things in weston.ini, Weston will keep disconnected connectors off and connected connectors on, turning things on and off appropriately when the connection status changes. It is harmless to have [output] sections "unused".

IOW, forget about udev. Udev rules are good for characterizing the device in question, and not much else. I think udev does not even track monitors as devices at all. Monitors do not have device nodes in /dev AFAIK. Hotplugs are delivered as uevents on the DRM device, yes, but they don't have information about the monitor. It's just a signal that "something about this DRM device changed" and userspace (e.g. Weston) needs to figure out what that was.

added 187 commits

• 13be7601...fe35ca2d - 186 commits from branch wayland:main
• dab1802a - backend-drm: Get optional WL_TRANSFORM from udev.

Compare with previous version

added 56 commits

• dab1802a...6ee6e76a - 55 commits from branch wayland:main
• 45c6e7c2 - backend-drm: Get optional WL_TRANSFORM from udev.

Compare with previous version

added Input label