Re: better way to detect new display
David Coppa wrote: > On Wed, Mar 1, 2017 at 11:49 AM, Raf Czlonka wrote: > > A while ago, Keith Packard wrote small display configuration tool > > called x-on-resize[0] which might be exactly what you are looking > > for but I have no idea how much effort would it be to get it > > working/ported on/to OpenBSD. > > > > [0] https://keithp.com/blogs/x-on-resize/ > > It builds out-of-the-box For anyone who doesn't have autotools installed or doesn't want to mess with it, you can also build by hand very easily. Simple patch to unautofuck below. cc -I/usr/X11R6/include -L/usr/X11R6/lib -lX11 -lXrandr x-on-resize.c diff --git a/x-on-resize.c b/x-on-resize.c index 55692c1..192db6f 100644 --- a/x-on-resize.c +++ b/x-on-resize.c @@ -21,7 +21,6 @@ #include #include #include -#include "config.h" struct output_info { struct output_info *next; @@ -148,7 +147,7 @@ main (int argc, char **argv) start = 1; break; case 'v': - printf("%s\n", PACKAGE_STRING); + printf("%s\n", "resize motherfucker"); exit(0); case 'h': default:
Re: better way to detect new display
Thank you for the suggestion. x-on-resize compiles and runs fine. It notices resizes, which I suspect I'll find useful down the road :) But, unfortunately, it doesn't notice when I plug/unplug my VGA monitor. I think I'll fall back to Plan B: map the F7 key to trigger a script which will run xrandr and switch displays to match what's plugged in. It's a little less magical, but it should get the job done and it avoids interrupting my audio every 5 seconds, since I'll only run xrandr when I'm trying to switch displays. On 03/01, David Coppa wrote: On Wed, Mar 1, 2017 at 11:49 AM, Raf Czlonka wrote: On Wed, Mar 01, 2017 at 10:14:39AM GMT, Marcus MERIGHI wrote: sc...@ggr.com (Scott Bonds), 2017.02.28 (Tue) 02:21 (CET): > I'm polling using xrandr to check whether a new display was plugged > in, so I can run a script to switch to it, i.e. plug in an external > VGA monitor and it lights up automatically, unplug it and my laptop > automatically switches back to using its internal display. I have wanted the same and found no way to avoid polling xrandr(1). If you find a way, would you be so kind to share the solution? > But, every time I run xrandr my (USB connected) audio stutters, which > makes me sad because I was hoping to poll for a new display every 5 > seconds, but that's not so great while listening to music. Does the --nograb parameter of xrandr(1) help? Marcus > Does anyone know of a better way to notice a newly plugged in > display...perhaps one that's more passive/efficient so as not to > provoke stuttering audio? I don't see any output from hotplugd that I > could use unfortunately, that seemed like the right place to look > first. I didn't notice anything I could use in the Xorg log either. > > !DSPAM:58b4d0ab225251121513987! Hi all, A while ago, Keith Packard wrote small display configuration tool called x-on-resize[0] which might be exactly what you are looking for but I have no idea how much effort would it be to get it working/ported on/to OpenBSD. [0] https://keithp.com/blogs/x-on-resize/ It builds out-of-the-box Thanks for making me know about x-on-resize, David
Re: better way to detect new display
On 03/01, Marcus MERIGHI wrote: sc...@ggr.com (Scott Bonds), 2017.02.28 (Tue) 02:21 (CET): I'm polling using xrandr to check whether a new display was plugged in, so I can run a script to switch to it, i.e. plug in an external VGA monitor and it lights up automatically, unplug it and my laptop automatically switches back to using its internal display. I have wanted the same and found no way to avoid polling xrandr(1). If you find a way, would you be so kind to share the solution? yes But, every time I run xrandr my (USB connected) audio stutters, which makes me sad because I was hoping to poll for a new display every 5 seconds, but that's not so great while listening to music. Does the --nograb parameter of xrandr(1) help? no, the sound still stutters, but that was a good idea
Re: better way to detect new display
On Wed, Mar 1, 2017 at 11:49 AM, Raf Czlonka wrote: > On Wed, Mar 01, 2017 at 10:14:39AM GMT, Marcus MERIGHI wrote: >> sc...@ggr.com (Scott Bonds), 2017.02.28 (Tue) 02:21 (CET): >> > I'm polling using xrandr to check whether a new display was plugged >> > in, so I can run a script to switch to it, i.e. plug in an external >> > VGA monitor and it lights up automatically, unplug it and my laptop >> > automatically switches back to using its internal display. >> >> I have wanted the same and found no way to avoid polling xrandr(1). >> >> If you find a way, would you be so kind to share the solution? >> >> > But, every time I run xrandr my (USB connected) audio stutters, which >> > makes me sad because I was hoping to poll for a new display every 5 >> > seconds, but that's not so great while listening to music. >> >> Does the --nograb parameter of xrandr(1) help? >> >> Marcus >> >> > Does anyone know of a better way to notice a newly plugged in >> > display...perhaps one that's more passive/efficient so as not to >> > provoke stuttering audio? I don't see any output from hotplugd that I >> > could use unfortunately, that seemed like the right place to look >> > first. I didn't notice anything I could use in the Xorg log either. >> > >> > !DSPAM:58b4d0ab225251121513987! >> > > Hi all, > > A while ago, Keith Packard wrote small display configuration tool > called x-on-resize[0] which might be exactly what you are looking > for but I have no idea how much effort would it be to get it > working/ported on/to OpenBSD. > > [0] https://keithp.com/blogs/x-on-resize/ It builds out-of-the-box Thanks for making me know about x-on-resize, David
Re: better way to detect new display
On Wed, Mar 01, 2017 at 10:14:39AM GMT, Marcus MERIGHI wrote: > sc...@ggr.com (Scott Bonds), 2017.02.28 (Tue) 02:21 (CET): > > I'm polling using xrandr to check whether a new display was plugged > > in, so I can run a script to switch to it, i.e. plug in an external > > VGA monitor and it lights up automatically, unplug it and my laptop > > automatically switches back to using its internal display. > > I have wanted the same and found no way to avoid polling xrandr(1). > > If you find a way, would you be so kind to share the solution? > > > But, every time I run xrandr my (USB connected) audio stutters, which > > makes me sad because I was hoping to poll for a new display every 5 > > seconds, but that's not so great while listening to music. > > Does the --nograb parameter of xrandr(1) help? > > Marcus > > > Does anyone know of a better way to notice a newly plugged in > > display...perhaps one that's more passive/efficient so as not to > > provoke stuttering audio? I don't see any output from hotplugd that I > > could use unfortunately, that seemed like the right place to look > > first. I didn't notice anything I could use in the Xorg log either. > > > > !DSPAM:58b4d0ab225251121513987! > Hi all, A while ago, Keith Packard wrote small display configuration tool called x-on-resize[0] which might be exactly what you are looking for but I have no idea how much effort would it be to get it working/ported on/to OpenBSD. [0] https://keithp.com/blogs/x-on-resize/ Regards, Raf
Re: better way to detect new display
On Wed, 01 Mar 2017, Marcus MERIGHI wrote: > sc...@ggr.com (Scott Bonds), 2017.02.28 (Tue) 02:21 (CET): >> I'm polling using xrandr to check whether a new display was plugged >> in, so I can run a script to switch to it, i.e. plug in an external >> VGA monitor and it lights up automatically, unplug it and my laptop >> automatically switches back to using its internal display. > > I have wanted the same and found no way to avoid polling xrandr(1). > > If you find a way, would you be so kind to share the solution? The Other Operating System has something called udev rules. I have a file called /etc/acpi/hotplug-monitor.sh which queries for connected displays and includes logic to set them up (falling back on xrandr --auto if nothing else makes sense). The file is invoked by udev, per another file named /etc/udev/rules.d/80-hotplug-monitor.rules which has this one line: SUBSYSTEM=="drm", ACTION=="change", RUN+="/etc/acpi/hotplug-monitor.sh" I don't have any OpenBSD box nearby (:C), but perhaps there's something in /var/log/* about a new monitor being plugged in? A process could follow the file and trigger events. <3,K.
Re: better way to detect new display
sc...@ggr.com (Scott Bonds), 2017.02.28 (Tue) 02:21 (CET): > I'm polling using xrandr to check whether a new display was plugged > in, so I can run a script to switch to it, i.e. plug in an external > VGA monitor and it lights up automatically, unplug it and my laptop > automatically switches back to using its internal display. I have wanted the same and found no way to avoid polling xrandr(1). If you find a way, would you be so kind to share the solution? > But, every time I run xrandr my (USB connected) audio stutters, which > makes me sad because I was hoping to poll for a new display every 5 > seconds, but that's not so great while listening to music. Does the --nograb parameter of xrandr(1) help? Marcus > Does anyone know of a better way to notice a newly plugged in > display...perhaps one that's more passive/efficient so as not to > provoke stuttering audio? I don't see any output from hotplugd that I > could use unfortunately, that seemed like the right place to look > first. I didn't notice anything I could use in the Xorg log either. > > !DSPAM:58b4d0ab225251121513987!
better way to detect new display
I'm polling using xrandr to check whether a new display was plugged in, so I can run a script to switch to it, i.e. plug in an external VGA monitor and it lights up automatically, unplug it and my laptop automatically switches back to using its internal display. But, every time I run xrandr my (USB connected) audio stutters, which makes me sad because I was hoping to poll for a new display every 5 seconds, but that's not so great while listening to music. Does anyone know of a better way to notice a newly plugged in display...perhaps one that's more passive/efficient so as not to provoke stuttering audio? I don't see any output from hotplugd that I could use unfortunately, that seemed like the right place to look first. I didn't notice anything I could use in the Xorg log either.