Feature request: To add `xrandr` output to Graphic section
I come here from Ask Ubuntu (As user) dealing much with hardware stacks issues. After some search that point me to the EDID repository and "Linux Hardware" site.
Graphic stack is changing relatively fast within GNU Linux/BSD systems.
Currently, I find many long standing questions which asked there without generic/canonical answer. More concerning: KMS drivers, Monitor Modes, High-DPI, Grub/VESA mode then things get complicated with Multi-Head/adapters (in Multi-Monitor setups) and Bad EDID's.
So, I would request adding the output of:
xrandr --verbose
It will show much about current setup (Modes, Transformations, Layout..) and how driver decoded EDID. Also xrandr is now a part of the graphic stack.
Side Note
-
There are many other cases where users use the Control GUI coming with binary drivers like nVidia and ATi. I am not too familiar with to know how to extract the active setup from them.
-
Some users add their workarounds to
xorg.conf.d/folder instead ofxorg.conffile. But scanning that may raise privacy issue.
The xrandr output is already collected by hw-probe in classic package (rpm, deb, etc.) and in appimage/docker. See this probe for example.
Not sure how to add xrandr program to hw-probe snap or flatpak w/o embedding whole X11 stack into it.
Thank you for quick reply. That's great, yeah I probably saw reports which are uploaded from snap app only.
I don't expect much, but I will give it a try: making a snap from scratch that can call xrandr. Then report back.
Even if you'll embed it to the snap, it will not be exactly the same as the users have in their environment outside the snap (different x11 versions, x11 vs wayland, different libdrm versions, etc.). However I guess the output of xrandr will be almost the same in most cases. But I may be wrong.
Hope I didn't miss some obvious. No need a copy of xrandr. It can call the system copy directly. Even with hwprobe, it is more better using same system tools.
I put strict confinement, on test snap. Still my script can call xrandr in the system. I didn't even put an interface.
Here my demo, snap/snapcraft.yaml
name: my-snap-name # you probably want to 'snapcraft register <name>'
base: core18 # the base snap is the execution environment for this snap
version: '0.1' # just for humans, typically '1.2+git' or '1.3.2'
summary: Single-line elevator pitch for your amazing snap # 79 char long summary
description: |
This is my-snap's description. You have a paragraph or two to tell the
most important story about your snap. Keep it under 100 words though,
we live in tweetspace and your description wants to look good in the snap
store.
grade: devel # must be 'stable' to release into candidate/stable channels
confinement: strict # use 'strict' once you have the right plugs and slots
parts:
my-part:
source: .
plugin: dump
organize:
xrandr-proxy: bin/xrandr-proxy
apps:
xrandr-proxy:
command: xrandr-proxy
and xrandr-proxy
#!/bin/sh
r="$(xrandr --verbose)"
echo 'XRANDR'
echo "$r"
xrandr --output Virtual1 --rotate left
sleep 5
xrandr --output Virtual1 --rotate normal
Could you please capture the output of which xrandr and echo $PATH from inside the snap?
For some reason hw-probe can't find xrandr in PATH.
Thanks.
-
That's my mistake, I was calling directly:
/snap/my-snap-name/current/bin/xrandr-proxyPATH →
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/snap/bin:/var/lib/snapd/snap/binxrandr →
/usr/bin/xrandrProbably, I break the confinement that way.
-
So I tried again using:
my-snap-name.xrandr-proxyPATH →
/snap/my-snap-name/x6/usr/sbin:/snap/my-snap-name/x6/usr/bin:/snap/my-snap-name/x6/sbin:/snap/my-snap-name/x6/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/gamesxrandr → blank
call fails:
/snap/my-snap-name/x6/bin/xrandr-proxy: 3: /snap/my-snap-name/x6/bin/xrandr-proxy: xrandr: not foundand
ls /usr/bin/does not include X11 tools. -
I will investigate more by activating some interfaces.
I could get it to work by staging the deb package containing xrandr and setting the x11 interface.
...
parts:
my-part:
source: .
plugin: dump
organize:
xrandr-proxy: bin/xrandr-proxy
debs:
plugin: nil
stage-packages:
- x11-xserver-utils
apps:
xrandr-proxy:
command: xrandr-proxy
plugs:
- x11
...
Anyway, it is possible to clean it and remove extra files at prime step. Snap package grew by 12MB.
I have doubts about: when it is a must to build a dependency from source?