There is no gdm.service, so where to add gdm session exec line?

English Install/Boot/Login
1

I want to control the colorspace that my gpu uses to display the desktop.

I have a PC that uses a TV as its display.
The color range of the TV is 16-235 (limited rgb), but the full range is being sent, resulting in crushment of darkest and brightest shades.

I prefer to figure out a way to manage colorspace in wayland, and found several references to this brad-x post on specifying colorspace in wayland, but I quickly found that:

So what is another way (or the right way) to add the following line to a gdm-session start sequence?

ExecStartPre=/usr/local/bin/proptest -M radeon -D /dev/dri/card0 48 connector 40 1

Or am I approaching this completely wrong? maybe there’s a tool for this?

-Cyril

2

Hi
What I would do is copy the service over to /etc/systemd/system and edit that one with your pre execute and see how it goes.

Can this be run as your user? If so, just add to the users ~/.profile so it gets run at login.

3

Hello.

Sounds good, but which service am I copying? I see services under /usr/lib/systemd/system, but no gdm.service.

Thanks for your help @malcolmlewis
-Cyril

4

Hi
You can create your own, just need to ensure it starts after the display-manager, then just make it an Exec=. Have a look at /etc/systemd/system/graphical.target.wants/display-manager.service

5

According to blog mentioned in the original post, it has to start before​ display-manager.

6

Thanks, I only have a cursory understanding of how these services work, but I was definitely feeling like the recommendation was in conflict with the directions of the original post.
To be fair, I asked specifically about gdm.service, and so got advice centered there-about.
The original post only states that the command needs to be run prior to the start of wayland, which (I think) is called by the display-manager service.

Because this is a permanent setup (pc will always be viewed through this rgb-limited display), I prefer that the command is run as soon as possible, so that it is active for ANY display, graphical or not, no matter the user.
I have observed that the command has immediate effect at run-level3, so in theory I could set before=graphical.target and also before=multi-user.target.

Thanks for the feedback, I will try some things…

or is there a way to run this via kms? or as a grub entry?
this kernel.org/kms page suggests that a kms rgb/colorspace entry is possible.
Time to go learn (break) some stuff…

-Cyril

7

**Success! **Thank you both. With a few cues from the afore-mentioned display-manager unit, I came up with the service file below ( tvRGB.service )
Feedback is welcome.


[Unit]
Description=Force tvRGB output
After=rc-local.service plymouth-start.service systemd-user-sessions.service
Before=display-manager.service

[Service]
Type=oneshot
ExecStart=-/bin/sh -c '/usr/bin/proptest -M radeon -D /dev/dri/card0 48 connector 40 1'

[Install]
WantedBy=multi-user.target
8

There is no need to use /bin/sh here, just use your command directly.

9

When I remove the /bin/sh, the service fails with:

code=exited, status=243

although when I systemctl start tvRGB.service from runlevel-3, the service runs successfully:

code=exited, status=0/SUCCESS

I’ll need to look into timing again…

10

This has become confusing and frustrating.
I can’t find any information on the exit-code “status=243”, and the command works.
The unit works as long as I manually start it prior to logging into a wayland session,
but the unit errors when auto started.

Any help is appreciated.

-Cyril


cyril@ten:~> systemctl status tvRGBa.service 
● tvRGBa.service - Force tvRGB output
   Loaded: loaded (/etc/systemd/system/tvRGBa.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Mon 2019-10-21 16:50:04 EDT; 2min 23s ago
  Process: 1748 ExecStart=-/usr/bin/proptest -M i915 -D /dev/dri/card0 68 connector 70 2 (code=exited, status=243)
 Main PID: 1748 (code=exited, status=243)
11

Hi
For the service type have you tried simple or forking?

12

This, might be the reason:

ExecStart=-/usr/bin/proptest -M i915 -D /dev/dri/card0 68 connector 70 2 (code=exited, status=243)

Notice the red “-”?
Maybe try:

ExecStart=/usr/bin/proptest -M i915 -D /dev/dri/card0 68 connector 70 2 (code=exited, status=243)

this instead. I could be wrong, though.

13

This and the fact that it works when you go via shell indirection suggests race condition. Unit is started too early before device /dev/dri/card0 becomes available. Unfortunately I do not see any easy way to delay unit initialization in this case. Could you provide full “journalctl -b” output after unit failed during system startup?

You are, sorry. Read systemd.service manual for explanation of this red “-”.

14

Regarding the dash in the command, it is designed for use in units with the ExecStartPre/Post= lines. In a single-command unit like the one(s) that I am attempting, it is neither problematic nor useful. Thanks for pointing it out though.

plymouth-start.service (or whatever combination is called by ‘splash=silent quiet’ ) causes the command to fail. I was occasionally disabling it via grub edit to try and visually see where things were going wrong, not realizing that was having an effect on the success or failure of the command, and resulting in some frustrating inconsistencies and tail-chasing.

I was initially thinking race-condition as well, specifically with udev, but found that the default dependencies force my unit to run after all relevant dependencies have been established (sysinit.target).

There have been a few other tweaks that seem to have helped as well, although I am still testing. Ideally I will find a unit that will work with plymouth enabled, but I won’t be bent on working that out.

  • Type matters. I am having the best results with Type=idle

Thank you all for your help with this.
-Cyril

15

That wasn’t the most clear post. I will reiterate.

The main culprit seems to have been the boot splash, or whatever group of services that are called when the kernel boot parameter ‘splash=silent quiet’ is used.
While the boot splash is running, any and all attempts to run that ‘proptest’ command fail.
My manual unit-start successes were because the splash/boot animation wasn’t running.
I was occasionally disabling it via grub edit to try and visually see where things were going wrong, not realizing that it was having an effect on the success or failure of the command, and resulting in some frustrating inconsistencies and tail-chasing.

Although early in testing, the service unit now seems to complete successfully more often than not, and the conditions where it fails are consistent and repeatable.

-Cyril

16

Makes sense. Plymouth is probably “master” of display and locks other consumers out.

Try to order your service after plymouth-quit-wait.service.