alex-courtis / xlayoutdisplay

Detects and arranges linux display outputs, using XRandR for detection and xrandr for arrangement.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Update to use modern procps-ng APIs

endigma opened this issue · comments

Doesn't work on modern procps-ng, they changed the API in 4.0.0. This blocks packaging/building on Void and probably other distros.

Other packages that depend on older procps have added compat patches to work with either, as which version is packaged varies by distro.

opentrack/opentrack@e050725

I might suggest for just seeing if Xorg is running that the presence of the socket be checked instead of proc?

Or maybe

#include <X11/Xlib.h>
#include <cstdlib>
#include <iostream>

bool displayIsValid()
{
    char* disp = getenv("DISPLAY");
    if ( disp==nullptr ) return false;
    Display* dpy = XOpenDisplay(disp);  
    if ( dpy==nullptr ) return false;
    XCloseDisplay(dpy);
    return true;
}

int main() {
    if ( displayIsValid() ) {
        std::cout << "Display is valid" << std::endl;
    }
}

(https://stackoverflow.com/questions/75683425/how-to-programmatically-c-c-verify-if-x11-forwarding-is-enabled)

Or maybe

That is indeed the elegant solution.

Unfortunately it results in a hung process when running the udev rule: https://wiki.archlinux.org/title/Udev#X_programs_in_RUN_rules_hang_when_no_X_server_is_present

Options:

  1. make code procps compatible
  2. alternative approach without procps

Possible alternative:
Have the rule use pidof in a script, something like

RUN+="/bin/sh -c 'pidof -q Xorg && xlayoutdisplay -w ...

We've already got the procps-ng dependency so it should be available.

Your thoughts?

I think anything that makes this software compile would be an upgrade, and in particular a scripted approach is a two way door and something could be improved later. I pretty much have it down to fixing this or rewriting the whole thing in Go or Rust out of spite for C++

  1. would involve removing the xorgRunning check as well as the procps dependency. It only exists for the rule.

I pretty much have it down to fixing this or rewriting the whole thing in Go or Rust

You're not the only one; there's a somewhat complete rust implementation: https://github.com/abusch/xld-rs

out of spite for C++

I am also done with C++. This is the last one.

Honestly, I'm done with X11 as well, my current display manager is for wayland: https://github.com/alex-courtis/way-displays.

I guess it really comes down to what even happens if you run the rest of the program when xorg is not running, does it just explode?

I am somewhat snowed under right now. Would you be able to put up a PR to completely remove procps and xorgRunning?

I'll deal with the rule after that...

I guess it really comes down to what even happens if you run the rest of the program when xorg is not running, does it just explode?

It's fine - XOpenDisplay fails fast and returns an error message.

Released on AUR.

Are you able to update the void package?

I am most grateful for your work!

There is no void package afaik