Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong screen geometry when using xrandr's --same-as #21

Open
The-Compiler opened this issue Sep 28, 2022 · 3 comments
Open

Wrong screen geometry when using xrandr's --same-as #21

The-Compiler opened this issue Sep 28, 2022 · 3 comments

Comments

@The-Compiler
Copy link
Contributor

I have three screens:

  • Internal laptop screen (eDP)
  • Portable USB-C screen (DisplayPort-0)
  • External HDMI projector (HDMI-A-0)

With that, I'm trying to set up xrandr so that I have my laptop screen, and the portable screen on the left of it, mirroring what people see on the projector. Thus, I run:

xrandr --output DisplayPort-0 --left-of eDP --auto
xrandr --output HDMI-A-0 --same-as DisplayPort-0 --auto
hc detect_monitors

which leads to xrandr reporting:

eDP connected primary 1920x1080+1920+0
HDMI-A-0 connected 1920x1080+0+0
DisplayPort-0 connected 1920x1080+0+0

and hc list_monitors saying:

0: 1920x1080+1920+0 with tag "2" [FOCUS]
1: 1920x1080+0+0 with tag "1"

however, I can't get barpyrus to show up on my laptop screen anymore: When I run either barpyrus 0 or barpyrus 1, the panel shows up on the left USB-C screen (probably picking DisplayPort and HDMI?). When I do barpyrus 2, I get:

monitor_rect: Cannot parse argument "2": No such monitor: 2
Traceback (most recent call last):
  File "/usr/bin/barpyrus", line 33, in <module>
    sys.exit(load_entry_point('barpyrus==0.0.0', 'console_scripts', 'barpyrus')())
  File "/usr/lib/python3.10/site-packages/barpyrus/mainloop.py", line 45, in main
    conf = get_user_config()
  File "/usr/lib/python3.10/site-packages/barpyrus/mainloop.py", line 39, in get_user_config
    return get_config(user_config_path())
  File "/usr/lib/python3.10/site-packages/barpyrus/mainloop.py", line 24, in get_config
    exec(code, global_vars)
  File "/home/florian/.config/barpyrus/config.py", line 309, in <module>
    bar = main()
  File "/home/florian/.config/barpyrus/config.py", line 261, in main
    x, y, monitor_w, _monitor_h = hc.monitor_rect(monitor)
  File "/usr/lib/python3.10/site-packages/barpyrus/hlwm.py", line 60, in monitor_rect
    x = int(geometry[0])
ValueError: invalid literal for int() with base 10: ''
@t-wissmann
Copy link
Owner

The monitor handling of lemonbar is just wrong in some cases. If you run barpyrus 0 or barpyrus 1, can you check the -g parameter to lemonbar? The geometry should still be correct, but the panel is shown at the wrong location (e.g. compare -g of lemonbar with what xwininfo reports).

The error message for barpyrus 2 seems correct, since there are only monitors 0 and 1 (only the long exception is unfortunate indeed).

@The-Compiler
Copy link
Contributor Author

Hmm, true! Indeed -g 1920x16+1920+0 and -g 1920x16+0+0 get passed to lemonbar, but both instances draw on the left monitor. Looks like this is LemonBoy/bar#163 probably.

The exception is a bit unfortunate indeed. Should HLWMInput.__call__ perhaps check the herbstclient exit code and bail out earlier with an exception if it's nonzero? Or are there hlwm commands being called which expect a nonzero exit code?

t-wissmann added a commit that referenced this issue Sep 28, 2022
This makes the HLWMInput() caller check that the exit code is 0.
Otherwise, an assertion and a backtrace is printed. Such a backtrace
would have been a more helpful error message in issue #21.
@t-wissmann
Copy link
Owner

I'd say __call__ should check the exit code per default. I've implemented the check in 0f78dcd.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants