I have a line in ~/.profile that calls a script which in turn includes: if [ "$desktop" = "kde" ] then echo "it is kde" xeyes -geometry 70x50+36+420 & xeyes -geometry 70x50+1750+420 & else echo "No kde, no xeyes" fi Which 'used to' give me 2 pairs of xeyes nestled between the two deskbar panels on the sides. Lately however I've ben getting 3 of them: https://imgur.com/2M5Zbil.png In this image (made to brag about my not usb but SATA desktop external bay) you can see my monitor showing the KDE plasma desktop photographed as part of my IKEA pine desktop then reloaded as a desktop wallpaper before that desktop being snapped up to imgur. I 'suspect' SDDM which begins with a lo-res desktop (the two pairs of xeyes on the left) but then they get redrawn as the desktop rolls into high-res with the left one being repeated in the same place as the first time. I have NO CLUE really, just poking around. What gives?
On Wed, 27 Nov 2024 20:00:52 -0500, bent fender <slowroller@trixtar.org> wrote:
I have a line in ~/.profile that calls a script which in turn includes:
if [ "$desktop" = "kde" ] then echo "it is kde" xeyes -geometry 70x50+36+420 & xeyes -geometry 70x50+1750+420 & else echo "No kde, no xeyes" fi
Which 'used to' give me 2 pairs of xeyes nestled between the two deskbar panels on the sides. Lately however I've ben getting 3 of them: https://imgur.com/2M5Zbil.png
Something to try (offset from the right side of the screen): xeyes -geometry 70x50+36+420 & xeyes -geometry 70x50-36+420 & Also, try commenting each line out one at a time to see which eyes disappear. -- Robert Webb
Thu, 28 Nov 2024 05:30:34 +0000 (UTC) Robert Webb via openSUSE Users <users@lists.opensuse.org> :
On Wed, 27 Nov 2024 20:00:52 -0500, bent fender <slowroller@trixtar.org> wrote:
I have a line in ~/.profile that calls a script which in turn includes:
if [ "$desktop" = "kde" ] then echo "it is kde" xeyes -geometry 70x50+36+420 & xeyes -geometry 70x50+1750+420 & else echo "No kde, no xeyes" fi
Which 'used to' give me 2 pairs of xeyes nestled between the two deskbar panels on the sides. Lately however I've ben getting 3 of them: https://imgur.com/2M5Zbil.png
Something to try (offset from the right side of the screen):
xeyes -geometry 70x50+36+420 & xeyes -geometry 70x50-36+420 &
seems to produce no change
Also, try commenting each line out one at a time to see which eyes disappear.
We're getting there :-) This gives only the two in the middle and on the right side: # xeyes -geometry 70x50+36+420 & xeyes -geometry 70x50-36+420 & And this one gives only the one on the left side: xeyes -geometry 70x50+36+420 & # xeyes -geometry 70x50-36+420 & I don't understand the syntax, I did once but cannot find the reference anymore. There are other issues with the desk bars in plasma6 but I don't want to cloud this topic yet.
-- Robert Webb
On 2024-11-28 06:58, bent fender wrote: ...
I don't understand the syntax, I did once but cannot find the reference anymore.
man xeyes -geometry geometry define the initial window geometry; see X(7). man 7 X No manual entry for X in section 7 man X No manual entry for X Crumbs :-( info X success? Opens "xboard.info. But I don't find "geometry" in the index. <https://man7.org/linux/man-pages/man7/man-pages.7.html> I can not find "geometry" either. Uh, it is not the X man page, but man on man. <https://linux.die.net/man/7/x> Geometry Specifications ------------------------ One of the advantages of using window systems instead of hardwired terminals is that applications don't have to be restricted to a particular size or location on the screen. Although the layout of windows on a display is controlled by the window manager that the user is running (described below), most X programs accept a command line argument of the form -geometry WIDTHxHEIGHT+XOFF+YOFF (where WIDTH, HEIGHT, XOFF, and YOFF are numbers) for specifying a preferred size and location for this application's main window. The WIDTH and HEIGHT parts of the geometry specification are usually measured in either pixels or characters, depending on the application. The XOFF and YOFF parts are measured in pixels and are used to specify the distance of the window from the left or right and top and bottom edges of the screen, respectively. Both types of offsets are measured from the indicated edge of the screen to the corresponding edge of the window. The X offset may be specified in the following ways: +XOFF The left edge of the window is to be placed XOFF pixels in from the left edge of the screen (i.e., the X coordinate of the window's origin will be XOFF). XOFF may be negative, in which case the window's left edge will be off the screen. -XOFF The right edge of the window is to be placed XOFF pixels in from the right edge of the screen. XOFF may be negative, in which case the window's right edge will be off the screen. The Y offset has similar meanings: +YOFF The top edge of the window is to be YOFF pixels below the top edge of the screen (i.e., the Y coordinate of the window's origin will be YOFF). YOFF may be negative, in which case the window's top edge will be off the screen. -YOFF The bottom edge of the window is to be YOFF pixels above the bottom edge of the screen. YOFF may be negative, in which case the window's bottom edge will be off the screen. Offsets must be given as pairs; in other words, in order to specify either XOFF or YOFF both must be present. Windows can be placed in the four corners of the screen using the following specifications: +0+0 upper left hand corner. -0+0 upper right hand corner. -0-0 lower right hand corner. +0-0 lower left hand corner. In the following examples, a terminal emulator is placed in roughly the center of the screen and a load average monitor, mailbox, and clock are placed in the upper right hand corner: xterm -fn 6x10 -geometry 80x24+30+200 & xclock -geometry 48x48-0+0 & xload -geometry 48x48-96+0 & xbiff -geometry 48x48-48+0 & -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
Thu, 28 Nov 2024 13:45:57 +0100 "Carlos E. R." <robin.listas@telefonica.net> :
On 2024-11-28 06:58, bent fender wrote:
...
I don't understand the syntax, I did once but cannot find the reference anymore.
man xeyes -geometry geometry define the initial window geometry; see X(7). man 7 X No manual entry for X in section 7 man X No manual entry for X
Crumbs :-(
info X
success? Opens "xboard.info.
But I don't find "geometry" in the index.
<https://man7.org/linux/man-pages/man7/man-pages.7.html>
I can not find "geometry" either. Uh, it is not the X man page, but man on man.
<https://linux.die.net/man/7/x>
Geometry Specifications ------------------------
One of the advantages of using window systems instead of hardwired terminals is that applications don't have to be restricted to a particular size or location on the screen. Although the layout of windows on a display is controlled by the window manager that the user is running (described below), most X programs accept a command line argument of the form -geometry WIDTHxHEIGHT+XOFF+YOFF (where WIDTH, HEIGHT, XOFF, and YOFF are numbers) for specifying a preferred size and location for this application's main window.
The WIDTH and HEIGHT parts of the geometry specification are usually measured in either pixels or characters, depending on the application. The XOFF and YOFF parts are measured in pixels and are used to specify the distance of the window from the left or right and top and bottom edges of the screen, respectively. Both types of offsets are measured from the indicated edge of the screen to the corresponding edge of the window. The X offset may be specified in the following ways:
+XOFF The left edge of the window is to be placed XOFF pixels in from the left edge of the screen (i.e., the X coordinate of the window's origin will be XOFF). XOFF may be negative, in which case the window's left edge will be off the screen. -XOFF The right edge of the window is to be placed XOFF pixels in from the right edge of the screen. XOFF may be negative, in which case the window's right edge will be off the screen.
The Y offset has similar meanings:
+YOFF The top edge of the window is to be YOFF pixels below the top edge of the screen (i.e., the Y coordinate of the window's origin will be YOFF). YOFF may be negative, in which case the window's top edge will be off the screen. -YOFF The bottom edge of the window is to be YOFF pixels above the bottom edge of the screen. YOFF may be negative, in which case the window's bottom edge will be off the screen.
Offsets must be given as pairs; in other words, in order to specify either XOFF or YOFF both must be present. Windows can be placed in the four corners of the screen using the following specifications:
+0+0 upper left hand corner. -0+0 upper right hand corner. -0-0 lower right hand corner. +0-0 lower left hand corner.
In the following examples, a terminal emulator is placed in roughly the center of the screen and a load average monitor, mailbox, and clock are placed in the upper right hand corner:
xterm -fn 6x10 -geometry 80x24+30+200 & xclock -geometry 48x48-0+0 & xload -geometry 48x48-96+0 & xbiff -geometry 48x48-48+0 &
-- Cheers / Saludos,
Carlos E. R. (from 15.5 x86_64 at Telcontar)
Thanks, I think it may once have been included in man xeyes, my bad. It all began when I wanted xeyes in my panel, starting with XFCE https://imgur.com/x2A9zHw.png piece of cake, XFCE has the widget, period With KDE I had to split each deskbar and stash the leering eyeballs just in the the provided notches like some murray eel https://www.imghippo.com/i/koU8862scc.png this worked fine with suse at least until Sept-2023 using -geometry 70x50+36+420 & xeyes -geometry 70x50-36+420 & Sometime AFTER that splashma-6 came and screwed it all up https://imgur.com/zO7uNrP.png both pairs drifting left Finally the other day, weeks after changing gpu to a Radeon [AMD/ATI] Juniper XT [Radeon HD 5770] sddm started booting my Tumbleweed desktop first in low-res mode, then in high-res and THAT's where I think it hit the fan bigtime. What I think is happening is that sddm starts the desktop in low-res and the close-together sets of eyeballs seen on the left come from there. Then comes hi-res when the exercise is repeated and that's where the second far apart set comes from, not the two on the right but the one on the left and the one on the far right. I only see 3 pairs but there are probably 4, the left one always in the same place! Once this issue is fixed I can work on the separate splasham-6 FUBAR which revolves around inadequate control of the 4 deskbars.
Hello, In the Message; Subject : Re: 3 pairs of xeyes? Message-ID : <20241128204357.f65eb98ee381055b2a459989@trixtar.org> Date & Time: Thu, 28 Nov 2024 20:43:57 -0500 [SF] == bent fender <slowroller@trixtar.org> has written: [...] SF> sddm started booting my Tumbleweed desktop SF> first in low-res mode, then in high-res and THAT's where I think it hit SF> the fan bigtime. [...] Please edit /etc/default/grub as follows; # you can see them in real GRUB with the command `vbeinfo' GRUB_GFXMODE="" to # you can see them in real GRUB with the command `vbeinfo' GRUB_GFXMODE="1092x1080" then, $ sudo grub2-mkconfig -o /boot/grub2/grub.config $ sudo reboot Best Regads. --- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ " Reading widely about things that don't seem immediately or practically useful, in the hope that what you learn now may prove meaningful later―that's pretty much the definition of a liberal- arts education. Who knew that one of its best defenders would turn out to be a computer scientist? " -- "What Does It Really Mean to Learn?" THE NEW YORKER --
Fri, 29 Nov 2024 14:03:17 +0900 Masaru Nomiya <nomiya@lake.dti.ne.jp> :
Hello,
In the Message;
Subject : Re: 3 pairs of xeyes? Message-ID : <20241128204357.f65eb98ee381055b2a459989@trixtar.org> Date & Time: Thu, 28 Nov 2024 20:43:57 -0500
[SF] == bent fender <slowroller@trixtar.org> has written:
[...] SF> sddm started booting my Tumbleweed desktop SF> first in low-res mode, then in high-res and THAT's where I think it hit SF> the fan bigtime. [...]
Please edit /etc/default/grub as follows;
# you can see them in real GRUB with the command `vbeinfo' GRUB_GFXMODE=""
to
# you can see them in real GRUB with the command `vbeinfo' GRUB_GFXMODE="1092x1080"
then,
$ sudo grub2-mkconfig -o /boot/grub2/grub.config
$ sudo reboot
Best Regads.
--- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ lake.dti.ne.jp
Thanks, but no cigar. I found GRUB_GFXMODE="auto" and edited it to GRUB_GFXMODE="1920x1080" but nothing has changed It seems to me that ~/.profile which hosts the xeyes calls is being run twice in two different resolutions.
Hello, In the Message; Subject : Re: 3 pairs of xeyes? Message-ID : <20241129210914.ec16d50e95fc6eb8774b297d@trixtar.org> Date & Time: Fri, 29 Nov 2024 21:09:14 -0500 [BF] == bent fender <slowroller@trixtar.org> has written: BF> Fri, 29 Nov 2024 14:03:17 +0900 BF> Masaru Nomiya <nomiya@lake.dti.ne.jp> : [...] BF>>> sddm started booting my Tumbleweed desktop BSF>>> first in low-res mode, then in high-res and THAT's where I think it hit BF>>> the fan bigtime. [...] MN> > Please edit /etc/default/grub as follows; MN> > MN> > MN> > # you can see them in real GRUB with the command `vbeinfo' MN> > GRUB_GFXMODE="" MN> > MN> > to MN> > MN> > # you can see them in real GRUB with the command `vbeinfo' MN> > GRUB_GFXMODE="1092x1080" MN> > MN> > then, MN> > MN> > $ sudo grub2-mkconfig -o /boot/grub2/grub.config MN> > MN> > $ sudo reboot BF> Thanks, but no cigar. I found BF> GRUB_GFXMODE="auto" BF> and edited it to BF> GRUB_GFXMODE="1920x1080" BF> but nothing has changed Hmm, something's different... 640x480, but the sddm theme screen appears in high resolution. Not after logging in. BF> It seems to me that ~/.profile which hosts the xeyes BF> calls is being run twice in two different resolutions. I felt the same way, so I made the suggestion. Please show the results of; $ xrandr Best Regards. --- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ " Reading widely about things that don't seem immediately or practically useful, in the hope that what you learn now may prove meaningful later―that's pretty much the definition of a liberal- arts education. Who knew that one of its best defenders would turn out to be a computer scientist? " -- "What Does It Really Mean to Learn?" THE NEW YORKER --
Sat, 30 Nov 2024 14:04:01 +0900 Masaru Nomiya <nomiya@lake.dti.ne.jp> :
Hello,
In the Message;
Subject : Re: 3 pairs of xeyes? Message-ID : <20241129210914.ec16d50e95fc6eb8774b297d@trixtar.org> Date & Time: Fri, 29 Nov 2024 21:09:14 -0500
[BF] == bent fender <slowroller@trixtar.org> has written:
BF> Fri, 29 Nov 2024 14:03:17 +0900 BF> Masaru Nomiya <nomiya@lake.dti.ne.jp> :
[...] BF>>> sddm started booting my Tumbleweed desktop BSF>>> first in low-res mode, then in high-res and THAT's where I think it hit BF>>> the fan bigtime. [...] MN> > Please edit /etc/default/grub as follows; MN> > MN> > MN> > # you can see them in real GRUB with the command `vbeinfo' MN> > GRUB_GFXMODE="" MN> > MN> > to MN> > MN> > # you can see them in real GRUB with the command `vbeinfo' MN> > GRUB_GFXMODE="1092x1080" MN> > MN> > then, MN> > MN> > $ sudo grub2-mkconfig -o /boot/grub2/grub.config MN> > MN> > $ sudo reboot
BF> Thanks, but no cigar. I found BF> GRUB_GFXMODE="auto" BF> and edited it to BF> GRUB_GFXMODE="1920x1080" BF> but nothing has changed
Hmm, something's different...
640x480, but the sddm theme screen appears in high resolution. Not after logging in.
BF> It seems to me that ~/.profile which hosts the xeyes BF> calls is being run twice in two different resolutions.
I felt the same way, so I made the suggestion.
Please show the results of;
$ xrandr
# xrandr Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 DisplayPort-0 disconnected (normal left inverted right x axis y axis) HDMI-0 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 521mm x 293mm 1920x1080 60.00*+ 50.00 59.94 1680x1050 59.88 1600x900 60.00 1280x1024 75.02 60.02 1440x900 59.90 1280x800 59.91 1152x864 75.00 1280x720 60.00 50.00 59.94 1024x768 75.03 70.07 60.00 832x624 74.55 800x600 72.19 75.00 60.32 56.25 720x576 50.00 720x480 60.00 59.94 640x480 75.00 72.81 66.67 60.00 59.94 720x400 70.08 DVI-0 connected (normal left inverted right x axis y axis) 1024x768 60.00 800x600 60.32 56.25 848x480 60.00 640x480 59.94 DVI-1 disconnected (normal left inverted right x axis y axis) in your next message:
Please show the results of;
$ find /etc /usr/share/X11 -name xorg.conf*
# find /etc /usr/share/X11 -name xorg.conf* /etc/X11/xorg.conf.d /usr/share/X11/xorg.conf.d By way of hardware it's been a very irregular 6 months for me, especially with video cards. I want 4k so I found a deal for $127 cad for an Rx590 I expect to have it in a week, hopefully it might even help some (although I'm convinced that this is not a card issue).
Hello, In the Message; Subject : Re: 3 pairs of xeyes? Message-ID : <20241130214227.a80870585d08dfa713f5ce35@trixtar.org> Date & Time: Sat, 30 Nov 2024 21:42:27 -0500 [BF] == bent fender <slowroller@trixtar.org> has written: BF> Sat, 30 Nov 2024 14:04:01 +0900 BF> Masaru Nomiya <nomiya@lake.dti.ne.jp> : [...] MN> > Please show the results of; MN> > $ xrandr BF> # xrandr BF> Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 BF> DisplayPort-0 disconnected (normal left inverted right x axis y axis) BF> HDMI-0 connected primary 1920x1080+0+0 (normal left inverted right x BF> axis y axis) 521mm x 293mm 1920x1080 60.00*+ 50.00 59.94 BF> 1680x1050 59.88 BF> 1600x900 60.00 BF> 1280x1024 75.02 60.02 BF> 1440x900 59.90 BF> 1280x800 59.91 BF> 1152x864 75.00 BF> 1280x720 60.00 50.00 59.94 BF> 1024x768 75.03 70.07 60.00 BF> 832x624 74.55 BF> 800x600 72.19 75.00 60.32 56.25 BF> 720x576 50.00 BF> 720x480 60.00 59.94 BF> 640x480 75.00 72.81 66.67 60.00 59.94 BF> 720x400 70.08 BF> DVI-0 connected (normal left inverted right x axis y axis) BF> 1024x768 60.00 BF> 800x600 60.32 56.25 BF> 848x480 60.00 BF> 640x480 59.94 BF> DVI-1 disconnected (normal left inverted right x axis y axis) [...] Your monitor cannot display a resolution of 1920x1080 using an HDMI connection, and the maximum resolution is 1680x1050. However, it is being forced to display this resolution, so the monitor is behaving abnormally. Please change to a DVI or DisplayPort connection. Isn't this written in the monitor's manual? Best Regards. --- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ " The production of A.I. seems to carry a powerful side effect: as the machines generate intelligence, they also generate mystery. Human misunderstanding endures, possibly a permanent condition. " -- "Was Linguistic A.I. Created by Accident?" THE NEW YORKER --
Sun, 01 Dec 2024 12:12:18 +0900 Masaru Nomiya <nomiya@lake.dti.ne.jp> :
Hello,
In the Message;
Subject : Re: 3 pairs of xeyes? Message-ID : <20241130214227.a80870585d08dfa713f5ce35@trixtar.org> Date & Time: Sat, 30 Nov 2024 21:42:27 -0500
[BF] == bent fender <slowroller@trixtar.org> has written:
BF> Sat, 30 Nov 2024 14:04:01 +0900 BF> Masaru Nomiya <nomiya@lake.dti.ne.jp> :
[...] MN> > Please show the results of;
MN> > $ xrandr
BF> # xrandr BF> Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 BF> DisplayPort-0 disconnected (normal left inverted right x axis y axis) BF> HDMI-0 connected primary 1920x1080+0+0 (normal left inverted right x BF> axis y axis) 521mm x 293mm 1920x1080 60.00*+ 50.00 59.94 BF> 1680x1050 59.88 BF> 1600x900 60.00 BF> 1280x1024 75.02 60.02 BF> 1440x900 59.90 BF> 1280x800 59.91 BF> 1152x864 75.00 BF> 1280x720 60.00 50.00 59.94 BF> 1024x768 75.03 70.07 60.00 BF> 832x624 74.55 BF> 800x600 72.19 75.00 60.32 56.25 BF> 720x576 50.00 BF> 720x480 60.00 59.94 BF> 640x480 75.00 72.81 66.67 60.00 59.94 BF> 720x400 70.08 BF> DVI-0 connected (normal left inverted right x axis y axis) BF> 1024x768 60.00 BF> 800x600 60.32 56.25 BF> 848x480 60.00 BF> 640x480 59.94 BF> DVI-1 disconnected (normal left inverted right x axis y axis) [...]
Your monitor cannot display a resolution of 1920x1080 using an HDMI connection, and the maximum resolution is 1680x1050. However, it is being forced to display this resolution, so the monitor is behaving abnormally.
Please change to a DVI or DisplayPort connection. Isn't this written in the monitor's manual?
The monitor is a samsung-F24T400FHN with two ports: RGB & HDMI and native resolution of 1920x1080, using the HDMI cable and connections. The GPU card has 2x DVI, 1x HDMI 1.3a, 1x DisplayPort 1.1
Best Regards.
--- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ " The production of A.I. seems to carry a powerful side effect: as the machines generate intelligence, they also generate mystery. Human misunderstanding endures, possibly a permanent condition. "
-- "Was Linguistic A.I. Created by Accident?" THE NEW YORKER --
Hello, In the Message; Subject : Re: 3 pairs of xeyes? Message-ID : <20241130224826.6aedd4cec035a947e3d6c3e3@trixtar.org> Date & Time: Sat, 30 Nov 2024 22:48:26 -0500 [BF] == bent fender <slowroller@trixtar.org> has written: BF> Sun, 01 Dec 2024 12:12:18 +0900 BF> Masaru Nomiya <nomiya@lake.dti.ne.jp> : [...] BF> >> # xrandr BF> >> Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 BF> >> DisplayPort-0 disconnected (normal left inverted right x axis y axis) BF> >> HDMI-0 connected primary 1920x1080+0+0 (normal left inverted right x BF> >> axis y axis) 521mm x 293mm 1920x1080 60.00*+ 50.00 59.94 BF> >> 1680x1050 59.88 BF> >> 1600x900 60.00 BF> >> 1280x1024 75.02 60.02 [...] MN> > Your monitor cannot display a resolution of 1920x1080 using an HDMI MN> > connection, and the maximum resolution is 1680x1050. However, it is MN> > being forced to display this resolution, so the monitor is behaving MN> > abnormally. MN> > Please change to a DVI or DisplayPort connection. Isn't MN> > this written in the monitor's manual? BF> The monitor is a samsung-F24T400FHN with two ports: RGB & HDMI and BF> native resolution of 1920x1080, using the HDMI cable and connections. BF> The GPU card has 2x DVI, 1x HDMI 1.3a, 1x DisplayPort 1.1 If you're right, the monitor is broken or it's a video card-related phenomenon. This is mine; $ xrandr Screen 0: minimum 8 x 8, current 3840 x 2160, maximum 32767 x 32767 DP-0 disconnected (normal left inverted right x axis y axis) DP-1 disconnected (normal left inverted right x axis y axis) DP-2 disconnected (normal left inverted right x axis y axis) DP-3 disconnected (normal left inverted right x axis y axis) HDMI-0 disconnected (normal left inverted right x axis y axis) DP-4 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 597mm x 336mm 3840x2160 60.00*+ 29.98 2560x1440 59.95 1920x1200 59.88 1920x1080 60.00 59.94 29.97 1680x1050 59.95 1600x1200 60.00 1600x900 60.00 1280x1024 60.02 1280x800 59.81 1280x720 60.00 59.94 1024x768 60.00 800x600 60.32 720x480 59.94 640x480 59.94 59.93 DP-5 disconnected (normal left inverted right x axis y axis) In any case, using it beyond the upper limit indicated by xrandr is a problem. Best Regards. --- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ " Reading widely about things that don't seem immediately or practically useful, in the hope that what you learn now may prove meaningful later―that's pretty much the definition of a liberal- arts education. Who knew that one of its best defenders would turn out to be a computer scientist? " -- "What Does It Really Mean to Learn?" THE NEW YORKER --
Sun, 01 Dec 2024 13:21:18 +0900 Masaru Nomiya <nomiya@lake.dti.ne.jp> :
Hello,
In the Message;
Subject : Re: 3 pairs of xeyes? Message-ID : <20241130224826.6aedd4cec035a947e3d6c3e3@trixtar.org> Date & Time: Sat, 30 Nov 2024 22:48:26 -0500
[BF] == bent fender <slowroller@trixtar.org> has written:
BF> Sun, 01 Dec 2024 12:12:18 +0900 BF> Masaru Nomiya <nomiya@lake.dti.ne.jp> :
[...] BF> >> # xrandr BF> >> Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 BF> >> DisplayPort-0 disconnected (normal left inverted right x axis y axis) BF> >> HDMI-0 connected primary 1920x1080+0+0 (normal left inverted right x BF> >> axis y axis) 521mm x 293mm 1920x1080 60.00*+ 50.00 59.94 BF> >> 1680x1050 59.88 BF> >> 1600x900 60.00 BF> >> 1280x1024 75.02 60.02 [...]
MN> > Your monitor cannot display a resolution of 1920x1080 using an HDMI MN> > connection, and the maximum resolution is 1680x1050. However, it is MN> > being forced to display this resolution, so the monitor is behaving MN> > abnormally.
MN> > Please change to a DVI or DisplayPort connection. Isn't MN> > this written in the monitor's manual?
BF> The monitor is a samsung-F24T400FHN with two ports: RGB & HDMI and BF> native resolution of 1920x1080, using the HDMI cable and connections. BF> The GPU card has 2x DVI, 1x HDMI 1.3a, 1x DisplayPort 1.1
If you're right, the monitor is broken or it's a video card-related phenomenon.
This is mine;
$ xrandr Screen 0: minimum 8 x 8, current 3840 x 2160, maximum 32767 x 32767 DP-0 disconnected (normal left inverted right x axis y axis) DP-1 disconnected (normal left inverted right x axis y axis) DP-2 disconnected (normal left inverted right x axis y axis) DP-3 disconnected (normal left inverted right x axis y axis) HDMI-0 disconnected (normal left inverted right x axis y axis) DP-4 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 597mm x 336mm 3840x2160 60.00*+ 29.98 2560x1440 59.95 1920x1200 59.88 1920x1080 60.00 59.94 29.97 1680x1050 59.95 1600x1200 60.00 1600x900 60.00 1280x1024 60.02 1280x800 59.81 1280x720 60.00 59.94 1024x768 60.00 800x600 60.32 720x480 59.94 640x480 59.94 59.93 DP-5 disconnected (normal left inverted right x axis y axis)
In any case, using it beyond the upper limit indicated by xrandr is a problem.
I have no idea where that's coming from but there's a new twist that popped up possibly on the last boot (just noticed it). NB: "I" haven't changed a thing! I'd have to stay up nights on end to do something like this on purpose, the left set now has three, just like that woman in the original Total-Recall movie and I get it only on one desktop in one activity. Other desktops/activities give veriable results: Desktop-1 Activity-1 (using to write this) https://imgur.com/CI6666c.png Desktop-1 Activities 2, 3 & 4 only the two pairs on the left Desktop-2 & 3 &4 Activity-1 NOTHING Activity 2 & 3 only the two pairs on the left Activity-4 NOTHING I get dizzy! Still, GPU cards only do what they are 'told' to do...
Hello, In the Message; Subject : Re: 3 pairs of xeyes? Message-ID : <20241130235404.989808fa6aa1811a7f9d16fb@trixtar.org> Date & Time: Sat, 30 Nov 2024 23:54:04 -0500 [BF] == bent fender <slowroller@trixtar.org> has written: BF> Sun, 01 Dec 2024 13:21:18 +0900 BF> Masaru Nomiya <nomiya@lake.dti.ne.jp> : BF> > Hello, BF> > BF> > In the Message; BF> > BF> > Subject : Re: 3 pairs of xeyes? BF> > Message-ID : <20241130224826.6aedd4cec035a947e3d6c3e3@trixtar.org> BF> > Date & Time: Sat, 30 Nov 2024 22:48:26 -0500 BF> > BF> > [BF] == bent fender <slowroller@trixtar.org> has written: BF> > BF> > BF> Sun, 01 Dec 2024 12:12:18 +0900 BF> > BF> Masaru Nomiya <nomiya@lake.dti.ne.jp> : BF> > BF> > [...] BF> > BF> >> # xrandr BF> > BF> >> Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 BF> > BF> >> DisplayPort-0 disconnected (normal left inverted right x axis y axis) BF> > BF> >> HDMI-0 connected primary 1920x1080+0+0 (normal left inverted right x BF> > BF> >> axis y axis) 521mm x 293mm 1920x1080 60.00*+ 50.00 59.94 BF> > BF> >> 1680x1050 59.88 BF> > BF> >> 1600x900 60.00 BF> > BF> >> 1280x1024 75.02 60.02 BF> > [...] I checked Samsung F24T40 Specifications, and I've understood. You want get th display mode; 1920 x 1080 pixels Full HD / 1080p Unfortunately, however, it operates in HD+ resolution mode, 1600x1200x60Hz, and this is the cause of the geometry abnormality. The solution is to operate it in Full HD resolution mode, and the method is as follows; $ xrandr --output HDMI-0 --scale 1.2x1.2 If it passes the test, edit /usr/share/sddm/scripts/Xsetup as follows; 1. if there is, remove xrandr --output Virtual1 --mode 1920x1080 then, add this line; 2. xrandr --output HDMI-0 --scale 1.2x1.2 Best Regards. --- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ " Reading widely about things that don't seem immediately or practically useful, in the hope that what you learn now may prove meaningful later―that's pretty much the definition of a liberal- arts education. Who knew that one of its best defenders would turn out to be a computer scientist? " -- "What Does It Really Mean to Learn?" THE NEW YORKER --
Fri, 06 Dec 2024 11:30:34 +0900 Masaru Nomiya <nomiya@lake.dti.ne.jp> :
Hello,
In the Message;
Subject : Re: 3 pairs of xeyes? Message-ID : <20241130235404.989808fa6aa1811a7f9d16fb@trixtar.org> Date & Time: Sat, 30 Nov 2024 23:54:04 -0500
[BF] == bent fender <slowroller@trixtar.org> has written:
BF> Sun, 01 Dec 2024 13:21:18 +0900 BF> Masaru Nomiya <nomiya@lake.dti.ne.jp> :
BF> > Hello, BF> > BF> > In the Message; BF> > BF> > Subject : Re: 3 pairs of xeyes? BF> > Message-ID : <20241130224826.6aedd4cec035a947e3d6c3e3@trixtar.org> BF> > Date & Time: Sat, 30 Nov 2024 22:48:26 -0500 BF> > BF> > [BF] == bent fender <slowroller@trixtar.org> has written: BF> > BF> > BF> Sun, 01 Dec 2024 12:12:18 +0900 BF> > BF> Masaru Nomiya <nomiya@lake.dti.ne.jp> : BF> > BF> > [...] BF> > BF> >> # xrandr BF> > BF> >> Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 BF> > BF> >> DisplayPort-0 disconnected (normal left inverted right x axis y axis) BF> > BF> >> HDMI-0 connected primary 1920x1080+0+0 (normal left inverted right x BF> > BF> >> axis y axis) 521mm x 293mm 1920x1080 60.00*+ 50.00 59.94 BF> > BF> >> 1680x1050 59.88 BF> > BF> >> 1600x900 60.00 BF> > BF> >> 1280x1024 75.02 60.02 BF> > [...]
I checked Samsung F24T40 Specifications, and I've understood.
You want get th display mode;
1920 x 1080 pixels Full HD / 1080p
Thank you very much for having taken the time but I think you looked up another monitor. https://www.displayspecifications.com/en/model/62791d08 This monitor has always been a 'full-HD' product (1920x1080) and I have never had issues with getting it to deliver that resolution. In any event, as you'll see from our other interchanges I have installed a more recent gpu-card and for any number of reasons the cited bug is for now rendered 'unsymptomatic' :-)
Unfortunately, however, it operates in HD+ resolution mode, 1600x1200x60Hz, and this is the cause of the geometry abnormality.
The solution is to operate it in Full HD resolution mode, and the method is as follows;
$ xrandr --output HDMI-0 --scale 1.2x1.2
If it passes the test, edit /usr/share/sddm/scripts/Xsetup as follows;
1. if there is, remove xrandr --output Virtual1 --mode 1920x1080
then, add this line;
2. xrandr --output HDMI-0 --scale 1.2x1.2
Best Regards.
--- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ " Reading widely about things that don't seem immediately or practically useful, in the hope that what you learn now may prove meaningful later―that's pretty much the definition of a liberal- arts education. Who knew that one of its best defenders would turn out to be a computer scientist? "
-- "What Does It Really Mean to Learn?" THE NEW YORKER --
Hello, In the Message; Subject : Re: 3 pairs of xeyes? Message-ID : <20241206002845.33631c7174d5d90d7177d96d@trixtar.org> Date & Time: Fri, 6 Dec 2024 00:28:45 -0500 [BF] == bent fender <slowroller@trixtar.org> has written: BF> Fri, 06 Dec 2024 11:30:34 +0900 BF> Masaru Nomiya <nomiya@lake.dti.ne.jp> : [...] BF> > BF> > BF> >> 1680x1050 59.88 BF> > BF> > BF> >> 1600x900 60.00 BF> > BF> > BF> >> 1280x1024 75.02 60.02 BF> > BF> > [...] BF> > BF> > I checked Samsung F24T40 Specifications, and I've understood. BF> > BF> > You want get th display mode; BF> > BF> > 1920 x 1080 pixels BF> > Full HD / 1080p BF> Thank you very much for having taken the time but I think you looked BF> up another monitor. BF> https://www.displayspecifications.com/en/model/62791d08 BF> This monitor has always been a 'full-HD' product (1920x1080) and I have BF> never had issues with getting it to deliver that resolution. BF> In any event, as you'll see from our other interchanges I have BF> installed a more recent gpu-card and for any number of reasons the BF> cited bug is for now rendered 'unsymptomatic' :-) I don't understand the situation, so please explain it in detail. In the Message; Subject : Re: 3 pairs of xeyes? Message-ID : <20241130214227.a80870585d08dfa713f5ce35@trixtar.org> Date & Time: Sat, 30 Nov 2024 21:42:27 -0500 [BF] == bent fender <slowroller@trixtar.org> has written: [...] BF> # xrandr BF> Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 BF> DisplayPort-0 disconnected (normal left inverted right x axis y axis) BF> HDMI-0 connected primary 1920x1080+0+0 (normal left inverted right x BF> axis y axis) 521mm x 293mm 1920x1080 60.00*+ 50.00 59.94 BF> 1680x1050 59.88 BF> 1600x900 60.00 BF> 1280x1024 75.02 60.02 [...] BF> 640x480 59.94 BF> DVI-1 disconnected (normal left inverted right x axis y axis) This was the HD+ resolution mode, right? When and how did you get the Full HD resolution mode? Is it because of the replacement of the video card used here? In the Message; Subject : AMD video resolution too low Message-ID : <20241111193605.ba7e836bcdde21129fd0ba47@trixtar.org> Date & Time: Mon, 11 Nov 2024 19:36:05 -0500 [BF] == bent fender <slowroller@trixtar.org> has written: BF> My temporary GPU card is: BF> VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] BF> Juniper XT [Radeon HD 5770] BF> About a month ago the GUI desktop on my most often used linux BF> installations went form high-res (1920x1080) to something rather very BF> low-res. I've never had VoidLinux in GUI yet at all, and all but BF> one of the others use one DM or another. In slackware I always did BF> "startx" and now that too goes to a low-res desktop. [...] Best Regards. --- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ "Microsoft is overhauling its cybersecurity strategy, called the Secure Future Initiative, to incorporate key security features into its core set of technology platforms and cloud services. " -- Microsoft overhauls cyber strategy to finally embrace security by default --
Fri, 06 Dec 2024 15:59:45 +0900 Masaru Nomiya <nomiya@lake.dti.ne.jp> :
Hello,
In the Message;
Subject : Re: 3 pairs of xeyes? Message-ID : <20241206002845.33631c7174d5d90d7177d96d@trixtar.org> Date & Time: Fri, 6 Dec 2024 00:28:45 -0500
[BF] == bent fender <slowroller@trixtar.org> has written:
BF> Fri, 06 Dec 2024 11:30:34 +0900 BF> Masaru Nomiya <nomiya@lake.dti.ne.jp> :
[...] BF> > BF> > BF> >> 1680x1050 59.88 BF> > BF> > BF> >> 1600x900 60.00 BF> > BF> > BF> >> 1280x1024 75.02 60.02 BF> > BF> > [...] BF> > BF> > I checked Samsung F24T40 Specifications, and I've understood. BF> > BF> > You want get th display mode; BF> > BF> > 1920 x 1080 pixels BF> > Full HD / 1080p
BF> Thank you very much for having taken the time but I think you looked BF> up another monitor.
BF> https://www.displayspecifications.com/en/model/62791d08
BF> This monitor has always been a 'full-HD' product (1920x1080) and I have BF> never had issues with getting it to deliver that resolution.
BF> In any event, as you'll see from our other interchanges I have BF> installed a more recent gpu-card and for any number of reasons the BF> cited bug is for now rendered 'unsymptomatic' :-)
I don't understand the situation, so please explain it in detail.
See my last to Robert. I was having a dual execution of my xeyes script but wasn't aware of that fact while both took place in the same screen size of 1920x1080 with the second iteration just covering the first one exactly. I next installed the Radeon HD-5770 card and either from that moment or from a time a little later I started getting 3 sets of eyeballs, actually 4 but #1 was exactly covered by #3. The reason for this was that the first set (called from my !/.profile & my-xeyes.bsh scripts) was created on a lo-res screen so it ended up all in the left half when the screen went hi-res. THAT's when I noticed that something was wrong (over time I had forgotten that I has a second call executed from kde-autostart). All is well now, or almost. An Rx-590 card briefly hid the problem because it never produced the lo-res intitial screen that he HD-5770 did. This morning I tested this new-old Rx-590 for 4k on my TV only to discover that it has no HDMI output at all so it TOO is going back to Amazon. I need an AMD 4k card for my Crosshair-IV-Formula & AMD Fx-8150 8-core cpu but there aren't many good Rx-590's still around and more recent ones probably won't work with my rig. Thanks for trying to help. -- Some people cannot think outside the box, forever complaining that they cannot find it.
Hello, In the Message; Subject : Re: 3 pairs of xeyes? Message-ID : <87v7w4owxt.wl-nomiya@lake.dti.ne.jp> Date & Time: Sun, 01 Dec 2024 13:21:18 +0900 [MN] == Masaru Nomiya <nomiya@lake.dti.ne.jp> has written: MN> Hello, MN> In the Message; MN> Subject : Re: 3 pairs of xeyes? MN> Message-ID : <20241130224826.6aedd4cec035a947e3d6c3e3@trixtar.org> MN> Date & Time: Sat, 30 Nov 2024 22:48:26 -0500 MN> [BF] == bent fender <slowroller@trixtar.org> has written: BF> Sun, 01 Dec 2024 12:12:18 +0900 BF> Masaru Nomiya <nomiya@lake.dti.ne.jp> : [...] BF> >> # xrandr BF> >> Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 BF> >> DisplayPort-0 disconnected (normal left inverted right x axis y axis) BF> >> HDMI-0 connected primary 1920x1080+0+0 (normal left inverted right x BF> >> axis y axis) 521mm x 293mm 1920x1080 60.00*+ 50.00 59.94 BF> >> 1680x1050 59.88 BF> >> 1600x900 60.00 BF> >> 1280x1024 75.02 60.02 [...] MN> > Your monitor cannot display a resolution of 1920x1080 using an HDMI MN> > connection, and the maximum resolution is 1680x1050. However, it is MN> > being forced to display this resolution, so the monitor is behaving MN> > abnormally. MN> > Please change to a DVI or DisplayPort connection. Isn't MN> > this written in the monitor's manual? BF> The monitor is a samsung-F24T400FHN with two ports: RGB & HDMI and BF> native resolution of 1920x1080, using the HDMI cable and connections. BF> The GPU card has 2x DVI, 1x HDMI 1.3a, 1x DisplayPort 1.1 MN> If you're right, the monitor is broken or it's a video card-related MN> phenomenon. From: https://wiki.archlinux.org/title/Xrandr xrandr Screen 0: minimum 320 x 200, current 3200 x 1080, maximum 8192 x 8192 VGA-1 disconnected (normal left inverted right x axis y axis) HDMI-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 531mm x 299mm 1920x1080 59.93 + 60.00* 50.00 59.94 1920x1080i 60.00 50.00 59.94 1680x1050 59.88 … You can use xrandr to set different resolution (must be present in the above list) on some output: $ xrandr --output HDMI-1 --mode 1920x1080 Best Regards. --- ┏━━┓彡 Masaru Nomiya mail-to: m.nomiya+suse @ gmail.com ┃＼／彡 ┗━━┛ Think! -- The IBM slogan --
Hello, In the Message; Subject : Re: 3 pairs of xeyes? Message-ID : <20241129210914.ec16d50e95fc6eb8774b297d@trixtar.org> Date & Time: Fri, 29 Nov 2024 21:09:14 -0500 [BF] == bent fender <slowroller@trixtar.org> has written: [...] BF> It seems to me that ~/.profile which hosts the xeyes BF> calls is being run twice in two different resolutions. Please show the results of; $ find /etc /usr/share/X11 -name xorg.conf* Best Regards. --- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ "To hire for skills, firms will need to implement robust and intentional changes in their hiring practices ― and change is hard." -- Employers don’t practice what they preach on skills-based hiring --
On Fri, 29 Nov 2024 21:09:14 -0500, bent fender <slowroller@trixtar.org> wrote:
Fri, 29 Nov 2024 14:03:17 +0900 Masaru Nomiya <nomiya@lake.dti.ne.jp> :
In the Message; Subject : Re: 3 pairs of xeyes? Message-ID : <20241128204357.f65eb98ee381055b2a459989@trixtar.org> Date & Time: Thu, 28 Nov 2024 20:43:57 -0500 [SF] == bent fender <slowroller@trixtar.org> has written: [...] SF> sddm started booting my Tumbleweed desktop SF> first in low-res mode, then in high-res and THAT's where I think it hit SF> the fan bigtime. [...]
It seems to me that ~/.profile which hosts the xeyes calls is being run twice in two different resolutions.
Are all three xeyes instances functional? That is, do they follow your cursor? How many processes are there?: ps -D '%F %T' -O ppid,pgid,lstart -C xeyes -- Robert Webb
Sun, 1 Dec 2024 02:35:59 +0000 (UTC) Robert Webb via openSUSE Users <users@lists.opensuse.org> :
On Fri, 29 Nov 2024 21:09:14 -0500, bent fender <slowroller@trixtar.org> wrote:
Fri, 29 Nov 2024 14:03:17 +0900 Masaru Nomiya <nomiya@lake.dti.ne.jp> :
In the Message; Subject : Re: 3 pairs of xeyes? Message-ID : <20241128204357.f65eb98ee381055b2a459989@trixtar.org> Date & Time: Thu, 28 Nov 2024 20:43:57 -0500 [SF] == bent fender <slowroller@trixtar.org> has written: [...] SF> sddm started booting my Tumbleweed desktop SF> first in low-res mode, then in high-res and THAT's where I think it hit SF> the fan bigtime. [...]
It seems to me that ~/.profile which hosts the xeyes calls is being run twice in two different resolutions.
Are all three xeyes instances functional? That is, do they follow your cursor?
Yes, no problem there!
How many processes are there?: ps -D '%F %T' -O ppid,pgid,lstart -C xeyes -- Robert Webb
# ps -D '%F %T' -O ppid,pgid,lstart -C xeyes PID PPID PGID STARTED S TTY TIME COMMAND 2528 1 2324 2024-11-30 21:28:00 S tty2 00:00:10 xeyes -geometry 70x50+36+420 2529 1 2324 2024-11-30 21:28:00 S tty2 00:00:10 xeyes -geometry 70x50-36+420 2886 2275 2877 2024-11-30 21:28:06 S ? 00:00:11 xeyes -geometry 70x50+36+420 2887 2275 2877 2024-11-30 21:28:06 S ? 00:00:11 xeyes -geometry 70x50-36+420 It seems to support my suspicion, two calls just as resolution changes. I think the 3 I see are #2 obscuring #1, #3, & #4
On Sat, 30 Nov 2024 22:28:23 -0500, bent fender <slowroller@trixtar.org> wrote:
Sun, 1 Dec 2024 02:35:59 +0000 (UTC) Robert Webb via openSUSE Users <users@lists.opensuse.org> :
On Fri, 29 Nov 2024 21:09:14 -0500, bent fender <slowroller@trixtar.org> wrote:
Fri, 29 Nov 2024 14:03:17 +0900 Masaru Nomiya <nomiya@lake.dti.ne.jp> :
In the Message; Subject : Re: 3 pairs of xeyes? Message-ID : <20241128204357.f65eb98ee381055b2a459989@trixtar.org> Date & Time: Thu, 28 Nov 2024 20:43:57 -0500 [SF] == bent fender <slowroller@trixtar.org> has written: [...] SF> sddm started booting my Tumbleweed desktop SF> first in low-res mode, then in high-res and THAT's where I think it hit SF> the fan bigtime. [...] It seems to me that ~/.profile which hosts the xeyes calls is being run twice in two different resolutions.
# ps -D '%F %T' -O ppid,pgid,lstart -C xeyes
PID PPID PGID STARTED S TTY TIME COMMAND
2528 1 2324 2024-11-30 21:28:00 S tty2 00:00:10 xeyes -geometry 70x50+36+420
2529 1 2324 2024-11-30 21:28:00 S tty2 00:00:10 xeyes -geometry 70x50-36+420
2886 2275 2877 2024-11-30 21:28:06 S ? 00:00:11 xeyes -geometry 70x50+36+420
2887 2275 2877 2024-11-30 21:28:06 S ? 00:00:11 xeyes -geometry 70x50-36+420
It seems to support my suspicion, two calls just as resolution changes. I think the 3 I see are #2 obscuring #1, #3, & #4
Yes. To trace whatever invokes ~/.profile, you could log its executions to the journal by adding this line to .profile: logger -i ".profile[$$] ppid $PPID($(ps -q $PPID -o args=))" That records the pid of the shell executing .profile, and the command of the shell's parent. Then, after booting, show the logged lines with: journalctl -g '^\.profile\[[0-9]+\] ppid ' -- Robert Webb
Sun, 1 Dec 2024 09:57:58 +0000 (UTC) Robert Webb via openSUSE Users <users@lists.opensuse.org> :
On Sat, 30 Nov 2024 22:28:23 -0500, bent fender <slowroller@trixtar.org> wrote:
Sun, 1 Dec 2024 02:35:59 +0000 (UTC) Robert Webb via openSUSE Users <users@lists.opensuse.org> :
On Fri, 29 Nov 2024 21:09:14 -0500, bent fender <slowroller@trixtar.org> wrote:
Fri, 29 Nov 2024 14:03:17 +0900 Masaru Nomiya <nomiya@lake.dti.ne.jp> :
In the Message; Subject : Re: 3 pairs of xeyes? Message-ID : <20241128204357.f65eb98ee381055b2a459989@trixtar.org> Date & Time: Thu, 28 Nov 2024 20:43:57 -0500 [SF] == bent fender <slowroller@trixtar.org> has written: [...] SF> sddm started booting my Tumbleweed desktop SF> first in low-res mode, then in high-res and THAT's where I think it hit SF> the fan bigtime. [...] It seems to me that ~/.profile which hosts the xeyes calls is being run twice in two different resolutions.
# ps -D '%F %T' -O ppid,pgid,lstart -C xeyes
PID PPID PGID STARTED S TTY TIME COMMAND
2528 1 2324 2024-11-30 21:28:00 S tty2 00:00:10 xeyes -geometry 70x50+36+420
2529 1 2324 2024-11-30 21:28:00 S tty2 00:00:10 xeyes -geometry 70x50-36+420
2886 2275 2877 2024-11-30 21:28:06 S ? 00:00:11 xeyes -geometry 70x50+36+420
2887 2275 2877 2024-11-30 21:28:06 S ? 00:00:11 xeyes -geometry 70x50-36+420
It seems to support my suspicion, two calls just as resolution changes. I think the 3 I see are #2 obscuring #1, #3, & #4
Yes. To trace whatever invokes ~/.profile, you could log its executions to the journal by adding this line to .profile:
logger -i ".profile[$$] ppid $PPID($(ps -q $PPID -o args=))"
That records the pid of the shell executing .profile, and the command of the shell's parent. Then, after booting, show the logged lines with:
journalctl -g '^\.profile\[[0-9]+\] ppid '
tons of these with different #'s: -- Boot d1764de000eb49a48ea74e11e5579f76 -- and then: Dec 01 16:23:04 localhost.localdomain UserMe[2443]: .profile[2362] ppid 2301(/usr/libexec/gdm/gdm-x-session --register-session --run-script /usr/bin/start> there is NO /usr/bin/start but if ">" is a wildcard then there is startplasma-wayland startplasma-x11 startx startxfce4 the first 2 are binaries the second 2 contain no 'profile'
On Sun, 1 Dec 2024 16:38:05 -0500, bent fender <slowroller@trixtar.org> wrote:
Sun, 1 Dec 2024 09:57:58 +0000 (UTC) Robert Webb via openSUSE Users <users@lists.opensuse.org> :
On Sat, 30 Nov 2024 22:28:23 -0500, bent fender <slowroller@trixtar.org> wrote:
Sun, 1 Dec 2024 02:35:59 +0000 (UTC) Robert Webb via openSUSE Users <users@lists.opensuse.org> :
On Fri, 29 Nov 2024 21:09:14 -0500, bent fender <slowroller@trixtar.org> wrote:
Fri, 29 Nov 2024 14:03:17 +0900 Masaru Nomiya <nomiya@lake.dti.ne.jp> :
In the Message; Subject : Re: 3 pairs of xeyes? Message-ID : <20241128204357.f65eb98ee381055b2a459989@trixtar.org> Date & Time: Thu, 28 Nov 2024 20:43:57 -0500 [SF] == bent fender <slowroller@trixtar.org> has written: [...] SF> sddm started booting my Tumbleweed desktop SF> first in low-res mode, then in high-res and THAT's where I think it hit SF> the fan bigtime. [...] It seems to me that ~/.profile which hosts the xeyes calls is being run twice in two different resolutions.
# ps -D '%F %T' -O ppid,pgid,lstart -C xeyes
PID PPID PGID STARTED S TTY TIME COMMAND
2528 1 2324 2024-11-30 21:28:00 S tty2 00:00:10 xeyes -geometry 70x50+36+420
2529 1 2324 2024-11-30 21:28:00 S tty2 00:00:10 xeyes -geometry 70x50-36+420
2886 2275 2877 2024-11-30 21:28:06 S ? 00:00:11 xeyes -geometry 70x50+36+420
2887 2275 2877 2024-11-30 21:28:06 S ? 00:00:11 xeyes -geometry 70x50-36+420
It seems to support my suspicion, two calls just as resolution changes. I think the 3 I see are #2 obscuring #1, #3, & #4
Yes. To trace whatever invokes ~/.profile, you could log its executions to the journal by adding this line to .profile:
logger -i ".profile[$$] ppid $PPID($(ps -q $PPID -o args=))"
That records the pid of the shell executing .profile, and the command of the shell's parent. Then, after booting, show the logged lines with:
journalctl -g '^\.profile\[[0-9]+\] ppid '
tons of these with different #'s: -- Boot d1764de000eb49a48ea74e11e5579f76 --
I guess you don't need any messages from before the most recent boot, so the '-b' option would be good. journalctl -b -g '^\.profile\[[0-9]+\] ppid '
and then: Dec 01 16:23:04 localhost.localdomain UserMe[2443]: .profile[2362] ppid 2301(/usr/libexec/gdm/gdm-x-session --register-session --run-script /usr/bin/start>
there is NO /usr/bin/start but if ">" is a wildcard then there is
The ">" shows the line is truncated to the window width. You can use the right arrow key to see the rest of it. So yes, it is a wildcard, for the rest of the line. :-) If you redirect the output to a file, there is no truncation.
startplasma-wayland startplasma-x11 startx startxfce4
the first 2 are binaries the second 2 contain no 'profile'
It is possible to see more about how ~/.profile gets invoked. I tried it myself, and describe it later below, but I don't think it matters. Your .profile created just the one log entry you show above, so it was executed just once, not twice. Yet, the xeyes commands were executed twice. In your initial post, you said that the xeyes commands are in a script which is called by .profile . That script must be getting called twice. If you don't see it in .profile, you could try commenting it out there and see if the xeyes are still created. _Description of my logging in ~/.profile_ In ~/.profile, I added the args for the current process to the log message: # Log the parent and the shell executing this .profile logger -i ".profile[$$] ppid $PPID($(ps -q $PPID -o args=)) ($(ps -q $$ -o args=))" And, somewhat redundantly, saved a 'ps' in tree format of all processes to get the full ancestry for .profile : [ ! -f ~/ps-profile ] || mv -T -- ~/ps-profile ~/ps-profile.old CMD_ENV=linux PS_PERSONALITY=linux \ ps -eH -o pid,pgid,sid,tname,time,args > ~/ps-profile After logging in (KDE), I edited the created ~/ps-profile to remove everything but the process executing .profile, and its ancestors. I wish it was possible to get that directly from 'ps'. Here it is: PID PGID SID TTY TIME COMMAND 1 1 1 ? 00:00:39 /usr/lib/systemd/systemd --switched-root --system --deserialize=48 1551 1526 1526 ? 00:00:00 /usr/bin/sddm 206988 1526 1526 ? 00:00:00 /usr/libexec/sddm/sddm-helper --socket /tmp/sddm-auth-d8ac3bde-04de-40f1-8aff-d5051b5fb1ce --id 3 --start /usr/bin/startplasma-x11 --user bitslam 207098 1526 1526 ? 00:00:00 -bash --login -c exec "${@}" - /usr//etc/X11/xdm/sys.xsession 207149 1526 1526 ? 00:00:00 ps -eH -o pid,pgid,sid,tname,time,args The log message showed the 'sddm-helper' and '-bash' command+args. -- Robert Webb
There's nothing wrong with the script that executes xeyes but there is something wrong with me when I call that script from within ~/.profile. It's something I've been warned about before (I think Carlos obliged once) but I just wouldn't listen. The way it was being called: bash my-xeyes-launch.bsh The way it should and now is being called: my-xeyes-launch.bsh I should be ashamed of it but that has never been one of my habbits. It would be nice though to understand HOW this makes a difference? With the latter (correct) call the low-res screen (initially thrown by ssdm or whatever DM being used) is free of the two pairs of eyeballs. As soon as as I use the former (wrong) call they are there again. Thanks to all for hints to keep me trying, especially Robert.
On Wed, 4 Dec 2024 21:07:00 -0500, bent fender <slowroller@trixtar.org> wrote:
There's nothing wrong with the script that executes xeyes but there is something wrong with me when I call that script from within ~/.profile. It's something I've been warned about before (I think Carlos obliged once) but I just wouldn't listen.
The way it was being called: bash my-xeyes-launch.bsh
The way it should and now is being called: my-xeyes-launch.bsh
I should be ashamed of it but that has never been one of my habbits. It would be nice though to understand HOW this makes a difference? With the latter (correct) call the low-res screen (initially thrown by ssdm or whatever DM being used) is free of the two pairs of eyeballs. As soon as as I use the former (wrong) call they are there again.
Well, this involves a bit of conjecture, but I have determined that you had inadvertently included this code in your launch script: #!/bin/sh four_eyes() { if [ "$desktop" = "kde" ] then echo "it is kde" xeyes -geometry 70x50+36+420 & xeyes -geometry 70x50-36+420 & else echo "No kde, no xeyes" fi } four_eyes # For bash, be extra certain that the xeyes are there if expr "/${BASH-}" : '.*/bash$' >/dev/null ;then sleep 6 four_eyes fi
Thanks to all for hints to keep me trying, especially Robert.
You're very welcome, Bent. -- Robert Webb ;-)
On 2024-12-05 03:07, bent fender wrote:
There's nothing wrong with the script that executes xeyes but there is something wrong with me when I call that script from within ~/.profile. It's something I've been warned about before (I think Carlos obliged once) but I just wouldn't listen.
The way it was being called: bash my-xeyes-launch.bsh
The way it should and now is being called: my-xeyes-launch.bsh
I should be ashamed of it but that has never been one of my habbits. It would be nice though to understand HOW this makes a difference? With the latter (correct) call the low-res screen (initially thrown by ssdm or whatever DM being used) is free of the two pairs of eyeballs. As soon as as I use the former (wrong) call they are there again.
It may be lack of coffee, but I don't see why it would matter. :-o I know I don't use the first method, though, unless the script is not marked executable.
Thanks to all for hints to keep me trying, especially Robert.
-- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
Thu, 5 Dec 2024 11:27:58 +0100 "Carlos E. R." <robin.listas@telefonica.net> :
On 2024-12-05 03:07, bent fender wrote:
There's nothing wrong with the script that executes xeyes but there is something wrong with me when I call that script from within ~/.profile. It's something I've been warned about before (I think Carlos obliged once) but I just wouldn't listen.
The way it was being called: bash my-xeyes-launch.bsh
The way it should and now is being called: my-xeyes-launch.bsh
I should be ashamed of it but that has never been one of my habbits. It would be nice though to understand HOW this makes a difference? With the latter (correct) call the low-res screen (initially thrown by ssdm or whatever DM being used) is free of the two pairs of eyeballs. As soon as as I use the former (wrong) call they are there again.
It may be lack of coffee, but I don't see why it would matter. :-o
I know I don't use the first method, though, unless the script is not marked executable.
Thanks to all for hints to keep me trying, especially Robert.
-- Cheers / Saludos,
Carlos E. R. (from 15.5 x86_64 at Telcontar)
Aaah, COME ON, GUYS, I DON'T NEED THIS! I thought I had it licked, even tried it back and forth to make sure I could duplicate, and I can duplicate. If I call without a prepended 'bash' I get two pairs of eyeballs, otherwise four. Funny thing is that on my laptop using the same splashma-6 kde this difference does NOT exist. So it has to do with graphics implementation or the vcard. On my laptop (morning and daytime) I get no lo-res DM screen at all, but on my destktop THAT's where the 'early' extra pair appears but then stays carried into the hi-res screen in the thus wrong place. Also, the phenomenon never materialized until a few months ago and I've been using the script with same call for it for many years. In the last few months I've been swapping cards like chopper blades and doing zypper-dups, that's all. Even with this current card everything worked fine until it just didn't anymore. I think I don't have a proper driver for it so I get a lo-res screen at first, then a virtual 1920x1080 that still has the two pairs of eyeballs from its low-res ancestor. I'm expecting another card tomorrow (Yunir RX 590 8GB), we'll se what that gives, for now here's the entire script (which I must have gotten from someone else because it certaily is not at the same level of syntax use that I am). #!/bin/sh if [ -n "$DISPLAY" ] then if [ "$XDG_CURRENT_DESKTOP" = "" ] then desktop=$(echo "$XDG_DATA_DIRS" | sed 's/.*\(xfce\|kde\| gnome\).*/\1/') else desktop=$XDG_CURRENT_DESKTOP fi desktop=${desktop,,} # convert to lower case echo "$desktop" else echo nodesktop no exeyes fi if [ "$desktop" = "kde" ] then echo it is kde xeyes -geometry 70x50+36+420 & xeyes -geometry 70x50+1810+420 & else echo No kde, no xeyes fi exit #done
Thu, 5 Dec 2024 08:21:55 -0500 bent fender <slowroller@trixtar.org> :
Thu, 5 Dec 2024 11:27:58 +0100 "Carlos E. R." <robin.listas@telefonica.net> :
On 2024-12-05 03:07, bent fender wrote:
There's nothing wrong with the script that executes xeyes but there is something wrong with me when I call that script from within ~/.profile. It's something I've been warned about before (I think Carlos obliged once) but I just wouldn't listen.
The way it was being called: bash my-xeyes-launch.bsh
The way it should and now is being called: my-xeyes-launch.bsh
I should be ashamed of it but that has never been one of my habbits. It would be nice though to understand HOW this makes a difference? With the latter (correct) call the low-res screen (initially thrown by ssdm or whatever DM being used) is free of the two pairs of eyeballs. As soon as as I use the former (wrong) call they are there again.
It may be lack of coffee, but I don't see why it would matter. :-o
I know I don't use the first method, though, unless the script is not marked executable.
Thanks to all for hints to keep me trying, especially Robert.
-- Cheers / Saludos,
Carlos E. R. (from 15.5 x86_64 at Telcontar)
Aaah, COME ON, GUYS, I DON'T NEED THIS! I thought I had it licked, even tried it back and forth to make sure I could duplicate, and I can duplicate. If I call without a prepended 'bash' I get two pairs of eyeballs, otherwise four. Funny thing is that on my laptop using the same splashma-6 kde this difference does NOT exist. So it has to do with graphics implementation or the vcard. On my laptop (morning and daytime) I get no lo-res DM screen at all, but on my destktop THAT's where the 'early' extra pair appears but then stays carried into the hi-res screen in the thus wrong place. Also, the phenomenon never materialized until a few months ago and I've been using the script with same call for it for many years. In the last few months I've been swapping cards like chopper blades and doing zypper-dups, that's all. Even with this current card everything worked fine until it just didn't anymore. I think I don't have a proper driver for it so I get a lo-res screen at first, then a virtual 1920x1080 that still has the two pairs of eyeballs from its low-res ancestor.
I'm expecting another card tomorrow (Yunir RX 590 8GB), we'll se what that gives, for now here's the entire script (which I must have gotten from someone else because it certaily is not at the same level of syntax use that I am).
#!/bin/sh if [ -n "$DISPLAY" ] then if [ "$XDG_CURRENT_DESKTOP" = "" ] then desktop=$(echo "$XDG_DATA_DIRS" | sed 's/.*\(xfce\|kde\| gnome\).*/\1/') else desktop=$XDG_CURRENT_DESKTOP fi
desktop=${desktop,,} # convert to lower case echo "$desktop" else echo nodesktop no exeyes fi
if [ "$desktop" = "kde" ] then echo it is kde xeyes -geometry 70x50+36+420 & xeyes -geometry 70x50+1810+420 & else echo No kde, no xeyes fi exit #done
An hour after that last post I received the new old gpu card Advanced Micro Devices, Inc. [AMD/ATI] Polaris 20 XL [Radeon RX 580 2048SP] (rev e7) The label on tyhe card says 590, inserted it and could not boot to a graphic desktop i.e could not boot at all. I tried a fresh install but it forced me to use ncurses because "you idiot your hardware does not meet minimums!" HUH??????? once TYW istalled the card works Did an (also forced ncurses) upgrade of existing isntallation and tested both ways of launching the subject script. Now I could not get 3 pairs of eyeballs even if I wanted to. Evidently the card OR its handling were the cause. BTW what's this about not meeting minimums with a card that isn't all that old? AND, since my monitor isn't 4k, is there a way that I can test this card for 4k operability?
On Thu, 5 Dec 2024 08:21:55 -0500, bent fender <slowroller@trixtar.org> wrote:
Thu, 5 Dec 2024 11:27:58 +0100 "Carlos E. R." <robin.listas@telefonica.net> :
On 2024-12-05 03:07, bent fender wrote:
The way it was being called: bash my-xeyes-launch.bsh
Since the first line of your script is '#!/bin/sh', you should use 'sh' instead of 'bash' when calling it as an argument to a shell invocation. That will avoid surprises, although for the script as it is, it won't matter. You have followed up with news that the double execution problem has gone away with your new graphics board. The software problem still exists, though, ready to bite again. I believe the script is being called also from some other piece of software besides the above line in your ~/.profile . To enable easy current and future debugging, I suggest replacing the line with: if [ -e ~/.profile-disable_xeyes_launch ] ;then echo === .profile xeyes disabled: ~/.profile-disable_xeyes_launch >&2 else sh my-xeyes-launch.bsh fi Then, when you want to check whether there is something else invoking xeyes: $ touch ~/.profile-disable_xeyes_launch Just remove the file to put your .profile functioning back to normal. -- Robert Webb
Thu, 5 Dec 2024 23:23:02 +0000 (UTC) Robert Webb via openSUSE Users <users@lists.opensuse.org> :
On Thu, 5 Dec 2024 08:21:55 -0500, bent fender <slowroller@trixtar.org> wrote:
Thu, 5 Dec 2024 11:27:58 +0100 "Carlos E. R." <robin.listas@telefonica.net> :
On 2024-12-05 03:07, bent fender wrote:
The way it was being called: bash my-xeyes-launch.bsh
Since the first line of your script is '#!/bin/sh', you should use 'sh' instead of 'bash' when calling it as an argument to a shell invocation. That will avoid surprises, although for the script as it is, it won't matter.
You have followed up with news that the double execution problem has gone away with your new graphics board. The software problem still exists, though, ready to bite again.
I believe the script is being called also from some other piece of software besides the above line in your ~/.profile . To enable easy current and future debugging, I suggest replacing the line with:
if [ -e ~/.profile-disable_xeyes_launch ] ;then echo === .profile xeyes disabled: ~/.profile-disable_xeyes_launch >&2 else sh my-xeyes-launch.bsh fi
Sounds like a good idea BUT, would this not nix the second execution which happens to be the one I'd want to keep? In a similar attack I would want to kill the first instance because that is the one that plays out on a lo-res screen later to occupy only the left half of its hi-res successor with its right edge eyeballs now in the middle. So instead of preventing a 2nd execution how would I terminate the first instance using the same srcipt? I can no longer duplicate the jinx however, it always started on the initially lo-res screen with the previous card. That lo-res screen no longer appears at all. I 'could' recover the old image and use the old card but I think I'll pass :-)
Then, when you want to check whether there is something else invoking xeyes:
$ touch ~/.profile-disable_xeyes_launch
Just remove the file to put your .profile functioning back to normal.
I'll try this just to see if the bug is still lurking, as it probably is. It's probably still executing twice but the second iteration just covers the first one since n=both arise on a hi-res screen. I inserted those lines into ~/.profile, logging in produced a 0 byte file ~/.profile-disable_xeyes_launch and the touch command against it returned nothing (what iis it supposed to do?). Then I figured what if I leave the file there, that should prevent the execution of the first xeyes command as well on the next log-in because the file exists. It didn't. This is a litlle over my head.
On Thu, 5 Dec 2024 19:33:40 -0500, bent fender <slowroller@trixtar.org> wrote:
Thu, 5 Dec 2024 23:23:02 +0000 (UTC) Robert Webb via openSUSE Users <users@lists.opensuse.org> :
On Thu, 5 Dec 2024 08:21:55 -0500, bent fender <slowroller@trixtar.org> wrote:
Thu, 5 Dec 2024 11:27:58 +0100 "Carlos E. R." <robin.listas@telefonica.net> :
On 2024-12-05 03:07, bent fender wrote:
The way it was being called: bash my-xeyes-launch.bsh
I believe the script is being called also from some other piece of software besides the above line in your ~/.profile . To enable easy current and future debugging, I suggest replacing the line with:
if [ -e ~/.profile-disable_xeyes_launch ] ;then echo === .profile xeyes disabled: ~/.profile-disable_xeyes_launch >&2 else sh my-xeyes-launch.bsh fi
Sounds like a good idea BUT, would this not nix the second execution which happens to be the one I'd want to keep? In a similar attack I would want to kill the first instance because that is the one that plays out on a lo-res screen later to occupy only the left half of its hi-res successor with its right edge eyeballs now in the middle. So instead of preventing a 2nd execution how would I terminate the first instance using the same srcipt?
Which one is the first one, though? Maybe it is the one in .profile . Getting the known one out of the way will help you find the other one, besides proving that it exists.
I can no longer duplicate the jinx however, it always started on the initially lo-res screen with the previous card. That lo-res screen no longer appears at all. I 'could' recover the old image and use the old card but I think I'll pass :-)
[...]
I'll try this just to see if the bug is still lurking, as it probably is. It's probably still executing twice but the second iteration just covers the first one since n=both arise on a hi-res screen.
Seems possible.
I inserted those lines into ~/.profile, logging in produced a 0 byte file ~/.profile-disable_xeyes_launch and the touch command against it returned nothing (what iis it supposed to do?).
The touch command creates the (empty) file, if it does not already exist. If it exists, then the modification time is updated to now. There is no output from the command. Logging in should not create that file, it should only read its directory entry. The touch command should not be in .profile . Use it manually when you want to disable one set of xeyes instances on following logins (for debugging).
[...] Then I figured what if I leave the file there, that should prevent the execution of the first xeyes command as well on the next log-in because the file exists. It didn't. This is a litlle over my head.
So the xeyes are still there. It probably did disable one set. Leave the "disable" file there and now it's time to look for where the other xeyes set is started from. Add this to your 'my-xeyes-launch.bsh' script, to capture its caller and parent, to the journal: logger -t xeyesLaunch -i -- "[$$]($(ps -q $$ -o args=)) ppid [$PPID]($(ps -q $PPID -o args=))" After logging in, view the messages with: journalctl -t xeyesLaunch -b You should check your KDE Autostart configuration to see whether the script is in there in addition to being called from ~/.profile . -- Robert Webb
On Fri, 6 Dec 2024 09:00:34 +0000 (UTC), Robert Webb via openSUSE Users <users@lists.opensuse.org> wrote:
Add this to your 'my-xeyes-launch.bsh' script, to capture its caller and parent, to the journal:
logger -t xeyesLaunch -i -- "[$$]($(ps -q $$ -o args=)) ppid [$PPID]($(ps -q $PPID -o args=))"
After logging in, view the messages with:
journalctl -t xeyesLaunch -b
Then, 'rm ~/.profile-disable_xeyes_launch' to re-enable the repeated call of the xeyes launch script and log in again. The messages will show which instance of the running script is the first one, the one you don't want. Another place to look for other calls of the launch script is your dot files: ( cd && find .[!.] .??* -prune -xtype f -exec grep 'my-xeyes-launch' -- {} + ) -- Robert Webb
Fri, 6 Dec 2024 21:09:40 +0000 (UTC) Robert Webb via openSUSE Users <users@lists.opensuse.org> :
On Fri, 6 Dec 2024 09:00:34 +0000 (UTC), Robert Webb via openSUSE Users <users@lists.opensuse.org> wrote:
Add this to your 'my-xeyes-launch.bsh' script, to capture its caller and parent, to the journal:
logger -t xeyesLaunch -i -- "[$$]($(ps -q $$ -o args=)) ppid [$PPID]($(ps -q $PPID -o args=))"
After logging in, view the messages with:
journalctl -t xeyesLaunch -b
Then, 'rm ~/.profile-disable_xeyes_launch' to re-enable the repeated call of the xeyes launch script and log in again. The messages will show which instance of the running script is the first one, the one you don't want.
Another place to look for other calls of the launch script is your dot files:
( cd && find .[!.] .??* -prune -xtype f -exec grep 'my-xeyes-launch' -- {} + )
this just produced "no entry"'
-- Robert Webb
The 'disable' routine was useful because it allowed me to isolate i.e. to know that the call in ~/.profile is in fact *the first* execution. Once I took that out with your script and the dummy 'touch' file the second execution continued. I looked at .config/autostart/ and there was a file I had earlier renamed to was-my-xeyes-launch.bsh forgetting the fact that the name of files in this folder doesn't make any difference. So I deleted it. Then I took out the dummy 'touched' file and sure enough I got the first set of eyeballs but since that takes place in lo-res they end up being in the left half-screen at 1920x1080. The double execution had probably been going on for many months _unnoticed_ because the low-res screen never existed so second set just covered the first set exactly. When the lo-res screen began showing up (for whatever reason) is when three pairs became visible. The residual part of the problem is that splashma-6 slews everything that would violate the deskbars margins even where there is no deskbar so I end up with this weird result: https://imgur.com/xwxi0r7.png If I do the ~/.profile call instead of kde-autostart then plasma is faced with a fait-accompli and the left eyes are exactyly where intended but I don't know how to trick the right eyes to go so much off the lo-res screen that they'll be just right in the hi-res final. Anyway, the short of the long is that your suggestion to look in autostart was the key! Thanks.
On Fri, 6 Dec 2024 20:57:37 -0500, bent fender <slowroller@trixtar.org> wrote:
The 'disable' routine was useful because it allowed me to isolate i.e. to know that the call in ~/.profile is in fact *the first* execution. Once I took that out with your script and the dummy 'touch' file the second execution continued. I looked at
.config/autostart/
and there was a file I had earlier renamed to
was-my-xeyes-launch.bsh
forgetting the fact that the name of files in this folder doesn't make any difference. So I deleted it. Then I took out the dummy 'touched' file and sure enough I got the first set of eyeballs but since that takes place in lo-res they end up being in the left half-screen at 1920x1080.
The double execution had probably been going on for many months _unnoticed_ because the low-res screen never existed so second set just covered the first set exactly. When the lo-res screen began showing up (for whatever reason) is when three pairs became visible.
Interesting results.
The residual part of the problem is that splashma-6 slews everything that would violate the deskbars margins even where there is no deskbar so I end up with this weird result:
If I do the ~/.profile call instead of kde-autostart then plasma is faced with a fait-accompli and the left eyes are exactyly where intended but I don't know how to trick the right eyes to go so much off the lo-res screen that they'll be just right in the hi-res final.
So Autostart is the right place to put xeyes start (desktop is set up in the final resolution), but then their placement fails because of Plasma desktop rules. That sucks. So what about instead using a Plasma applet, widget, plasmoid, or whatever they are called? One that could be within the panels (deskbars). There is one which you can add (download) from the Add Widgets menu, 'Cursor Eyes'. [1]
Anyway, the short of the long is that your suggestion to look in autostart was the key! Thanks.
[1] https://github.com/luisbocanegra/plasma-cursor-eyes/blob/main/README.md -- Robert Webb
Sat, 7 Dec 2024 06:27:27 +0000 (UTC) Robert Webb via openSUSE Users <users@lists.opensuse.org> :
On Fri, 6 Dec 2024 20:57:37 -0500, bent fender <slowroller@trixtar.org> wrote:
The 'disable' routine was useful because it allowed me to isolate i.e. to know that the call in ~/.profile is in fact *the first* execution. Once I took that out with your script and the dummy 'touch' file the second execution continued. I looked at
.config/autostart/
and there was a file I had earlier renamed to
was-my-xeyes-launch.bsh
forgetting the fact that the name of files in this folder doesn't make any difference. So I deleted it. Then I took out the dummy 'touched' file and sure enough I got the first set of eyeballs but since that takes place in lo-res they end up being in the left half-screen at 1920x1080.
The double execution had probably been going on for many months _unnoticed_ because the low-res screen never existed so second set just covered the first set exactly. When the lo-res screen began showing up (for whatever reason) is when three pairs became visible.
Interesting results.
The residual part of the problem is that splashma-6 slews everything that would violate the deskbars margins even where there is no deskbar so I end up with this weird result:
If I do the ~/.profile call instead of kde-autostart then plasma is faced with a fait-accompli and the left eyes are exactyly where intended but I don't know how to trick the right eyes to go so much off the lo-res screen that they'll be just right in the hi-res final.
So Autostart is the right place to put xeyes start (desktop is set up in the final resolution), but then their placement fails because of Plasma desktop rules. That sucks.
So what about instead using a Plasma applet, widget, plasmoid, or whatever they are called? One that could be within the panels (deskbars).
There is one which you can add (download) from the Add Widgets menu, 'Cursor Eyes'. [1]
Anyway, the short of the long is that your suggestion to look in autostart was the key! Thanks.
[1] https://github.com/luisbocanegra/plasma-cursor-eyes/blob/main/README.md
-- Robert Webb
Didn't know about that widget but I stay away from 3rd party addons as much as I can, not sure if that's a kde component per-se or not (but I will look at it). As far as I'm concerned 'xeyes' exists as it has for a very long time and all you need it a drop-in to some autostart foldet OR a ~/.profile call so that it might work exactly the the same way in any of my installed systems and regardless of the desktop being used. THAT is still THE Linux way. XCFE did the same thing, insread of ACCOMODATING an existing and perfectly adequate applet they too cooked up one that works only in XFCE, puke.
On Sat, 7 Dec 2024 08:40:20 -0500, bent fender <slowroller@trixtar.org> wrote:
Sat, 7 Dec 2024 06:27:27 +0000 (UTC) Robert Webb via openSUSE Users <users@lists.opensuse.org> :
On Fri, 6 Dec 2024 20:57:37 -0500, bent fender <slowroller@trixtar.org> wrote:
The residual part of the problem is that splashma-6 slews everything that would violate the deskbars margins even where there is no deskbar so I end up with this weird result:
If I do the ~/.profile call instead of kde-autostart then plasma is faced with a fait-accompli and the left eyes are exactyly where intended but I don't know how to trick the right eyes to go so much off the lo-res screen that they'll be just right in the hi-res final.
There is one which you can add (download) from the Add Widgets menu, 'Cursor Eyes'. [1]
[1] https://github.com/luisbocanegra/plasma-cursor-eyes/blob/main/README.md
Didn't know about that widget but I stay away from 3rd party addons as much as I can, not sure if that's a kde component per-se or not (but I will look at it). As far as I'm concerned 'xeyes' exists as it has for a very long time and all you need it a drop-in to some autostart foldet OR a ~/.profile call so that it might work exactly the the same way in any of my installed systems and regardless of the desktop being used. THAT is still THE Linux way. XCFE did the same thing, insread of ACCOMODATING an existing and perfectly adequate applet they too cooked up one that works only in XFCE, puke.
Reasonable viewpoint. OK, so I experimented with other ways of invoking xeyes. Your call from ~/.profile happened too early; the screen resolution wasn't set yet. The call from Autostart, after the window manager (Plasma) was in control, would not allow placement in the deskbar panels. But, there is a script file, ~/.xprofile, that, if it exists, is meant to be invoked during X initialization before the window manager is started. You would put the xeyes commands into that. Some display managers will automatically source ~/.xprofile [2], but on openSUSE Tumbleweed, sddm does not. So, as suggested by that reference, I created, not the full xinitrc, but just an xinitrc drop-in script [3] to source it. With the xeyes commands in ~/.xprofile [4], logging in at first showed the eyes near the edge of an otherwise blank screen, but a moment later, when the KDE desktop was displayed, the eyes were moved to just touching the panel, but not overlapping it. So the end result is the same as you had with Autostart. The display manager was able to move the xeyes out of the way even though they were started before the manager. So this experiment was a fail, but I am attaching the two scripts [3] [4] so you may try them. Maybe some modification will make them useful. In any case, ~/.xprofile would be an appropriate place to put other per user X initialization commands. The scripts include logging, which you can view with: journalctl -t xinit -b Instead of a hack like this, what you need is a general wrapper command that would place a GUI app (like xeyes, or well, xclock) in the panel region of KDE Plasma. [2] https://wiki.archlinux.org/title/Xprofile [3] /etc/X11/xinit/xinitrc.d/10-source_xprofile (attached) [4] ~/.xprofile (attached) -- Robert Webb
Tue, 10 Dec 2024 07:40:43 +0000 (UTC) Robert Webb via openSUSE Users <users@lists.opensuse.org> :
On Sat, 7 Dec 2024 08:40:20 -0500, bent fender <slowroller@trixtar.org> wrote:
Sat, 7 Dec 2024 06:27:27 +0000 (UTC) Robert Webb via openSUSE Users <users@lists.opensuse.org> :
On Fri, 6 Dec 2024 20:57:37 -0500, bent fender <slowroller@trixtar.org> wrote:
The residual part of the problem is that splashma-6 slews everything that would violate the deskbars margins even where there is no deskbar so I end up with this weird result:
If I do the ~/.profile call instead of kde-autostart then plasma is faced with a fait-accompli and the left eyes are exactyly where intended but I don't know how to trick the right eyes to go so much off the lo-res screen that they'll be just right in the hi-res final.
There is one which you can add (download) from the Add Widgets menu, 'Cursor Eyes'. [1]
[1] https://github.com/luisbocanegra/plasma-cursor-eyes/blob/main/README.md
Didn't know about that widget but I stay away from 3rd party addons as much as I can, not sure if that's a kde component per-se or not (but I will look at it). As far as I'm concerned 'xeyes' exists as it has for a very long time and all you need it a drop-in to some autostart foldet OR a ~/.profile call so that it might work exactly the the same way in any of my installed systems and regardless of the desktop being used. THAT is still THE Linux way. XCFE did the same thing, insread of ACCOMODATING an existing and perfectly adequate applet they too cooked up one that works only in XFCE, puke.
Reasonable viewpoint. OK, so I experimented with other ways of invoking xeyes.
Nothing wrong with that, I didn't mean to throw any pebbles :-)
Your call from ~/.profile happened too early; the screen resolution wasn't set yet.
OK, but it was never a problem before
The call from Autostart, after the window manager (Plasma) was in control, would not allow placement in the deskbar panels. But, there is a script file, ~/.xprofile, that, if it exists, is meant to be invoked during X initialization before the window manager is started. You would put the xeyes commands into that.
Some display managers will automatically source ~/.xprofile [2], but on openSUSE Tumbleweed, sddm does not. So, as suggested by that reference, I created, not the full xinitrc, but just an xinitrc drop-in script [3] to source it.
With the xeyes commands in ~/.xprofile [4], logging in at first showed the eyes near the edge of an otherwise blank screen, but a moment later, when the KDE desktop was displayed, the eyes were moved to just touching the panel, but not overlapping it. So the end result is the same as you had with Autostart. The display manager was able to move the xeyes out of the way even though they were started before the manager.
So this experiment was a fail, but I am attaching the two scripts [3] [4] so you may try them. Maybe some modification will make them useful. In any case, ~/.xprofile would be an appropriate place to put other per user X initialization commands. The scripts include logging, which you can view with:
journalctl -t xinit -b
I missed your comments about .xprofile, sounds interesting
Instead of a hack like this, what you need is a general wrapper command that would place a GUI app (like xeyes, or well, xclock) in the panel region of KDE Plasma.
I began with xeyes in XFCE where the widget went nicely into their panel but after kde had forced me to place it between deskbars as in this 'buntu-studio desktop I once had https://imgur.com/screenshot-1swkolq I actually got to like this placement better ... leering like like a moray eel from among cracks in the coral :-))
[2] https://wiki.archlinux.org/title/Xprofile [3] /etc/X11/xinit/xinitrc.d/10-source_xprofile (attached) [4] ~/.xprofile (attached)
-- Robert Webb
Swamped right now, looking for an EATX taichi white mobo at _my_ price...
Tue, 10 Dec 2024 07:40:43 +0000 (UTC) Robert Webb via openSUSE Users <users@lists.opensuse.org> :
On Sat, 7 Dec 2024 08:40:20 -0500, bent fender <slowroller@trixtar.org> wrote:
Sat, 7 Dec 2024 06:27:27 +0000 (UTC) Robert Webb via openSUSE Users <users@lists.opensuse.org> :
On Fri, 6 Dec 2024 20:57:37 -0500, bent fender <slowroller@trixtar.org> wrote:
The residual part of the problem is that splashma-6 slews everything that would violate the deskbars margins even where there is no deskbar so I end up with this weird result:
If I do the ~/.profile call instead of kde-autostart then plasma is faced with a fait-accompli and the left eyes are exactyly where intended but I don't know how to trick the right eyes to go so much off the lo-res screen that they'll be just right in the hi-res final.
There is one which you can add (download) from the Add Widgets menu, 'Cursor Eyes'. [1]
[1] https://github.com/luisbocanegra/plasma-cursor-eyes/blob/main/README.md
Didn't know about that widget but I stay away from 3rd party addons as much as I can, not sure if that's a kde component per-se or not (but I will look at it). As far as I'm concerned 'xeyes' exists as it has for a very long time and all you need it a drop-in to some autostart foldet OR a ~/.profile call so that it might work exactly the the same way in any of my installed systems and regardless of the desktop being used. THAT is still THE Linux way. XCFE did the same thing, insread of ACCOMODATING an existing and perfectly adequate applet they too cooked up one that works only in XFCE, puke.
Reasonable viewpoint. OK, so I experimented with other ways of invoking xeyes. Your call from ~/.profile happened too early; the screen resolution wasn't set yet. The call from Autostart, after the window manager (Plasma) was in control, would not allow placement in the deskbar panels. But, there is a script file, ~/.xprofile, that, if it exists, is meant to be invoked during X initialization before the window manager is started. You would put the xeyes commands into that.
Some display managers will automatically source ~/.xprofile [2], but on openSUSE Tumbleweed, sddm does not. So, as suggested by that reference, I created, not the full xinitrc, but just an xinitrc drop-in script [3] to source it.
Yes, thank you. At that time I didn't have time but I followed through by copying the 10-source_xprofile into the /etc/X11/xinit/xinitrc.d autoload (clip) folder. And I copied the home-xprofile to ~/.xprofile which did not exist. So the migration/insertion works as expected. I disabled KDE autostart and the journal log shows NO multiple sourcing. Dec 12 20:12:08 localhost.localdomain xinit[2420]: user: /etc/X11/xinit/xinitrc.d/10-source_xprofile sourcing: /home/u3/.xprofile Dec 12 20:12:08 localhost.localdomain xinit[2422]: u3: executing: /home/u3/.xprofile: 2nd time?: no But Then I got THIS :-))) https://imgur.com/nzTHYuR.png I don't know what "-biblicallyAccurate" does but taking it out produces https://imgur.com/DP467qz.png The insertion still takes place on a lo0res screen and STAYS ant the lo-res screen X- coordinate when the screen goes hi-res. It doesn't look like .xprofil;e is being executed in a hi-res screen. I should maybe try to force the right pair to off screen by several hundred pixels on the right in the lo-res screen. When Carlos linked the syntax (which I've lost since!) there was mention about the X going off screen if negative but I cannot figure that out because it already IS negative.
With the xeyes commands in ~/.xprofile [4], logging in at first showed the eyes near the edge of an otherwise blank screen, but a moment later, when the KDE desktop was displayed, the eyes were moved to just touching the panel, but not overlapping it. So the end result is the same as you had with Autostart. The display manager was able to move the xeyes out of the way even though they were started before the manager.
So this experiment was a fail, but I am attaching the two scripts [3] [4] so you may try them. Maybe some modification will make them useful. In any case, ~/.xprofile would be an appropriate place to put other per user X initialization commands. The scripts include logging, which you can view with:
journalctl -t xinit -b
Instead of a hack like this, what you need is a general wrapper command that would place a GUI app (like xeyes, or well, xclock) in the panel region of KDE Plasma.
[2] https://wiki.archlinux.org/title/Xprofile [3] /etc/X11/xinit/xinitrc.d/10-source_xprofile (attached) [4] ~/.xprofile (attached)
-- Robert Webb
On Thu, 12 Dec 2024 20:42:36 -0500, bent fender <slowroller@trixtar.org> wrote:
Tue, 10 Dec 2024 07:40:43 +0000 (UTC) Robert Webb via openSUSE Users <users@lists.opensuse.org> :
On Sat, 7 Dec 2024 08:40:20 -0500, bent fender <slowroller@trixtar.org> wrote:
[...]
Reasonable viewpoint. OK, so I experimented with other ways of invoking xeyes. Your call from ~/.profile happened too early; the screen resolution wasn't set yet. The call from Autostart, after the window manager (Plasma) was in control, would not allow placement in the deskbar panels. But, there is a script file, ~/.xprofile, that, if it exists, is meant to be invoked during X initialization before the window manager is started. You would put the xeyes commands into that.
Some display managers will automatically source ~/.xprofile [2], but on openSUSE Tumbleweed, sddm does not. So, as suggested by that reference, I created, not the full xinitrc, but just an xinitrc drop-in script [3] to source it.
Yes, thank you. At that time I didn't have time but I followed through by copying the 10-source_xprofile into the /etc/X11/xinit/xinitrc.d autoload (clip) folder. And I copied the home-xprofile to ~/.xprofile which did not exist. So the migration/insertion works as expected. I disabled KDE autostart and the journal log shows NO multiple sourcing.
Dec 12 20:12:08 localhost.localdomain xinit[2420]: user: /etc/X11/xinit/xinitrc.d/10-source_xprofile
sourcing: /home/u3/.xprofile Dec 12 20:12:08 localhost.localdomain xinit[2422]: u3: executing: /home/u3/.xprofile: 2nd time?: no
But Then I got THIS :-)))
I don't know what "-biblicallyAccurate" does but taking it out produces
The eyes of an angel, but less gross than (biblical) reality, so to speak.
The insertion still takes place on a lo0res screen and STAYS ant the lo-res screen X- coordinate when the screen goes hi-res. It doesn't look like .xprofil;e is being executed in a hi-res screen.
That is very strange. According to the documentation I have read, at the point in the start up process when .xprofile executes, 'X' is supposed to already be set up such that graphical apps may be, and are suggested to be, invoked from .xprofile . I think your X server may be starting up in the wrong resolution, and it isn't from something happening earlier. And then the desktop manager starts and sets the correct resolution, maybe?
I should maybe try to force the right pair to off screen by several hundred pixels on the right in the lo-res screen. When Carlos linked the syntax (which I've lost since!) there was mention about the X going off screen if negative but I cannot figure that out because it already IS negative.
The syntax involves using +XOFF or -XOFF, but then when they say, "XOFF may be negative", it means using +-<offset> or --<offset>. The syntax is on the 'X' man page, in the "GEOMETRY SPECIFICATIONS" section. That man page is not normally installed even though it is referred to by other installed X man pages. Install the 'xorg-docs' package to get it.
With the xeyes commands in ~/.xprofile [4], logging in at first showed the eyes near the edge of an otherwise blank screen, but a moment later, when the KDE desktop was displayed, the eyes were moved to just touching the panel, but not overlapping it. So the end result is the same as you had with Autostart. The display manager was able to move the xeyes out of the way even though they were started before the manager.
So this experiment was a fail, but I am attaching the two scripts [3] [4] so you may try them. Maybe some modification will make them useful. In any case, ~/.xprofile would be an appropriate place to put other per user X initialization commands. The scripts include logging, which you can view with:
journalctl -t xinit -b
[2] https://wiki.archlinux.org/title/Xprofile [3] /etc/X11/xinit/xinitrc.d/10-source_xprofile (attached) [4] ~/.xprofile (attached)
-- Robert Webb
On 2024-12-13 05:03, Robert Webb via openSUSE Users wrote:
The syntax is on the 'X' man page, in the "GEOMETRY SPECIFICATIONS" section. That man page is not normally installed even though it is referred to by other installed X man pages. Install the 'xorg-docs' package to get it.
Ah! There it is, thanks. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
Fri, 13 Dec 2024 04:03:29 +0000 (UTC) Robert Webb via openSUSE Users <users@lists.opensuse.org> :
On Thu, 12 Dec 2024 20:42:36 -0500, bent fender <slowroller@trixtar.org> wrote:
Tue, 10 Dec 2024 07:40:43 +0000 (UTC) Robert Webb via openSUSE Users <users@lists.opensuse.org> :
On Sat, 7 Dec 2024 08:40:20 -0500, bent fender <slowroller@trixtar.org> wrote:
[...]
Reasonable viewpoint. OK, so I experimented with other ways of invoking xeyes. Your call from ~/.profile happened too early; the screen resolution wasn't set yet. The call from Autostart, after the window manager (Plasma) was in control, would not allow placement in the deskbar panels. But, there is a script file, ~/.xprofile, that, if it exists, is meant to be invoked during X initialization before the window manager is started. You would put the xeyes commands into that.
Some display managers will automatically source ~/.xprofile [2], but on openSUSE Tumbleweed, sddm does not. So, as suggested by that reference, I created, not the full xinitrc, but just an xinitrc drop-in script [3] to source it.
Yes, thank you. At that time I didn't have time but I followed through by copying the 10-source_xprofile into the /etc/X11/xinit/xinitrc.d autoload (clip) folder. And I copied the home-xprofile to ~/.xprofile which did not exist. So the migration/insertion works as expected. I disabled KDE autostart and the journal log shows NO multiple sourcing.
Dec 12 20:12:08 localhost.localdomain xinit[2420]: user: /etc/X11/xinit/xinitrc.d/10-source_xprofile
sourcing: /home/u3/.xprofile Dec 12 20:12:08 localhost.localdomain xinit[2422]: u3: executing: /home/u3/.xprofile: 2nd time?: no
But Then I got THIS :-)))
I don't know what "-biblicallyAccurate" does but taking it out produces
The eyes of an angel, but less gross than (biblical) reality, so to speak.
The insertion still takes place on a lo0res screen and STAYS ant the lo-res screen X- coordinate when the screen goes hi-res. It doesn't look like .xprofil;e is being executed in a hi-res screen.
That is very strange. According to the documentation I have read, at the point in the start up process when .xprofile executes, 'X' is supposed to already be set up such that graphical apps may be, and are suggested to be, invoked from .xprofile . I think your X server may be starting up in the wrong resolution, and it isn't from something happening earlier. And then the desktop manager starts and sets the correct resolution, maybe?
What if I don't have the proper driver installed and sddm tries with what's at hand before KDE fakes a virtual resolution or something along those 'above my head' lines? How can I test for having the proper driver aboard and in use? This entire GPU episode of several months now has me spinning dizzy but I think the behaviour started at a time when the same card HAD been in use for weeks with no other changes except for software updates. I'm building a new box in months coming so it will vaporise but meanwhile this mystery still has me stumped.
I should maybe try to force the right pair to off screen by several hundred pixels on the right in the lo-res screen. When Carlos linked the syntax (which I've lost since!) there was mention about the X going off screen if negative but I cannot figure that out because it already IS negative.
The syntax involves using +XOFF or -XOFF, but then when they say, "XOFF may be negative", it means using +-<offset> or --<offset>.
I'll try the --XOFF again tonight to see if I can push them off screen in the hope of hiiting a ho-res 1900 X or so.
The syntax is on the 'X' man page, in the "GEOMETRY SPECIFICATIONS" section. That man page is not normally installed even though it is referred to by other installed X man pages. Install the 'xorg-docs' package to get it.
With the xeyes commands in ~/.xprofile [4], logging in at first showed the eyes near the edge of an otherwise blank screen, but a moment later, when the KDE desktop was displayed, the eyes were moved to just touching the panel, but not overlapping it. So the end result is the same as you had with Autostart. The display manager was able to move the xeyes out of the way even though they were started before the manager.
So this experiment was a fail, but I am attaching the two scripts [3] [4] so you may try them. Maybe some modification will make them useful. In any case, ~/.xprofile would be an appropriate place to put other per user X initialization commands. The scripts include logging, which you can view with:
journalctl -t xinit -b
[2] https://wiki.archlinux.org/title/Xprofile [3] /etc/X11/xinit/xinitrc.d/10-source_xprofile (attached) [4] ~/.xprofile (attached)
-- Robert Webb
On 2024-12-13 15:11, bent fender wrote:
Fri, 13 Dec 2024 04:03:29 +0000 (UTC) Robert Webb via openSUSE Users <users@lists.opensuse.org> :
There is a hack you can do. In any of the possible places to call a script at desktop startup, call another script in background (&). This other script starts has: sleep 5 xeyes ... -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
Fri, 13 Dec 2024 15:58:43 +0100 "Carlos E. R." <robin.listas@telefonica.net> :
On 2024-12-13 15:11, bent fender wrote:
Fri, 13 Dec 2024 04:03:29 +0000 (UTC) Robert Webb via openSUSE Users <users@lists.opensuse.org> :
There is a hack you can do.
In any of the possible places to call a script at desktop startup, call another script in background (&).
This other script starts has:
sleep 5 xeyes ...
did that too (in ~/.xprofile this time) no cigar I think the problem is the appearance of the low res screen at all. WHAT IS IT DOING THERE? SDDM comes up in it, with the 5 second sleep it's obvious that it's staying in that screen. When the timer rings THEN the eyballs appear and THEN kde rolls into 1920x10980 but the eyes, having been opened in low res stay at the coordinates SDDM was in. If I call xeyes in the KDE autostart the situation is more 'normal' because KDE stars a 1920x1080 screen and the eyes get placed in that and thus correctly. The Y coordinate is affected the same way but that's less evident because it's not being called to screen lower limit. sleep 5 xeyes -geometry 70x50+36+420 & xeyes -geometry 70x50-36+420 &
On 2024-12-14 03:05, bent fender wrote:
Fri, 13 Dec 2024 15:58:43 +0100 "Carlos E. R." <robin.listas@telefonica.net> :
On 2024-12-13 15:11, bent fender wrote:
Fri, 13 Dec 2024 04:03:29 +0000 (UTC) Robert Webb via openSUSE Users <users@lists.opensuse.org> :
There is a hack you can do.
In any of the possible places to call a script at desktop startup, call another script in background (&).
This other script starts has:
sleep 5 xeyes ...
did that too (in ~/.xprofile this time)
no cigar
I think the problem is the appearance of the low res screen at all.
WHAT IS IT DOING THERE?
SDDM comes up in it, with the 5 second sleep it's obvious that it's staying in that screen. When the timer rings THEN the eyballs appear and THEN kde rolls into 1920x10980
That's probably because you are not calling a second script in background. The screen is waiting for ~/.xprofile to finish. You have to detach the second script.
but the eyes, having been opened in low res stay at the coordinates SDDM was in. If I call xeyes in the KDE autostart the situation is more 'normal' because KDE stars a 1920x1080 screen and the eyes get placed in that and thus correctly. The Y coordinate is affected the same way but that's less evident because it's not being called to screen lower limit.
sleep 5 xeyes -geometry 70x50+36+420 & xeyes -geometry 70x50-36+420 &
-- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
Sat, 14 Dec 2024 04:21:26 +0100 "Carlos E. R." <robin.listas@telefonica.net> :
On 2024-12-14 03:05, bent fender wrote:
Fri, 13 Dec 2024 15:58:43 +0100 "Carlos E. R." <robin.listas@telefonica.net> :
On 2024-12-13 15:11, bent fender wrote:
Fri, 13 Dec 2024 04:03:29 +0000 (UTC) Robert Webb via openSUSE Users <users@lists.opensuse.org> :
There is a hack you can do.
In any of the possible places to call a script at desktop startup, call another script in background (&).
This other script starts has:
sleep 5 xeyes ...
did that too (in ~/.xprofile this time)
no cigar
I think the problem is the appearance of the low res screen at all.
WHAT IS IT DOING THERE?
SDDM comes up in it, with the 5 second sleep it's obvious that it's staying in that screen. When the timer rings THEN the eyballs appear and THEN kde rolls into 1920x10980
That's probably because you are not calling a second script in background. The screen is waiting for ~/.xprofile to finish. You have to detach the second script.
You lost me, ~/.xprofile *is* the 2nd script nowe and in this test there are no others. The xeyes call is made in ~/.xprofile and it does not call my own script indirectly as before from ~/.profile # /etc/X11/xinit/xinitrc.d/10-source_xprofile 2024-12-09 rw # to be sourced # # see: https://wiki.archlinux.org/title/Xprofile # {/usr,}/etc/X11/xinit/xinitrc.common F_drop_in_script="/etc/X11/xinit/xinitrc.d/10-source_xprofile" for F_xprofile in /etc/xprofile ~/.xprofile ;do if [ -f "$F_xprofile" ] ;then logger -t 'xinit' -i -- \ "$(id -nu): ${F_drop_in_script} sourcing: $F_xprofile" . "$F_xprofile" fi done unset F_xprofile F_drop_in_script # ~/.xprofile 2024-12-09 # to be sourced # # Commands to execute at the beginning of the X user session, before # the window manager is started # # see: https://wiki.archlinux.org/title/Xprofile # /etc/X11/xinit/xinitrc.d/10-source_xprofile # {/usr,}/etc/X11/xinit/xinitrc.common logger -t 'xinit' -i -- \ "$(id -nu): executing: $HOME/.xprofile: 2nd time?: $ {DOT_XPROFILE_BEEN_SOURCED:-no}" # Source this file only once test x"${DOT_XPROFILE_BEEN_SOURCED-}" != x'yes' || return 0 export DOT_XPROFILE_BEEN_SOURCED=yes xeyes -geometry 140x100+36+420 -biblicallyAccurate & xeyes -geometry 70x50-36+420 &
On Sat, 14 Dec 2024 04:21:26 +0100, "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2024-12-14 03:05, bent fender wrote:
Fri, 13 Dec 2024 15:58:43 +0100 "Carlos E. R." <robin.listas@telefonica.net> :
There is a hack you can do. In any of the possible places to call a script at desktop startup, call another script in background (&).
This other script starts has:
sleep 5 xeyes ...
did that too (in ~/.xprofile this time) no cigar
I think the problem is the appearance of the low res screen at all.
WHAT IS IT DOING THERE?
SDDM comes up in it, with the 5 second sleep it's obvious that it's staying in that screen. When the timer rings THEN the eyballs appear and THEN kde rolls into 1920x10980
That's probably because you are not calling a second script in background. The screen is waiting for ~/.xprofile to finish. You have to detach the second script.
Yes, without having the sleep command, which the xeyes commands wait for, also in the background (executed asynchronously), then the whole startup process waits till after the sleep ends, and it defeats the purpose of using the sleep to try to run the xeyes at a later point in the process. So you are suggesting (in .xprofile or other init script): sleep_then_xeyes_script & An alternative that does the same thing, but without a separate script, is to put the commands in a sub-shell, run in the background: ( sleep 5 xeyes -geometry 70x50+36+420 & xeyes -geometry 70x50-36+420 & ) &
but the eyes, having been opened in low res stay at the coordinates SDDM was in. If I call xeyes in the KDE autostart the situation is more 'normal' because KDE stars a 1920x1080 screen and the eyes get placed in that and thus correctly. The Y coordinate is affected the same way but that's less evident because it's not being called to screen lower limit.
sleep 5 xeyes -geometry 70x50+36+420 & xeyes -geometry 70x50-36+420 &
-- Robert Webb
On 2024-12-15 10:34, Robert Webb via openSUSE Users wrote:
On Sat, 14 Dec 2024 04:21:26 +0100, "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2024-12-14 03:05, bent fender wrote:
Fri, 13 Dec 2024 15:58:43 +0100 "Carlos E. R." <robin.listas@telefonica.net> :
There is a hack you can do. In any of the possible places to call a script at desktop startup, call another script in background (&).
This other script starts has:
sleep 5 xeyes ...
did that too (in ~/.xprofile this time) no cigar
I think the problem is the appearance of the low res screen at all.
WHAT IS IT DOING THERE?
SDDM comes up in it, with the 5 second sleep it's obvious that it's staying in that screen. When the timer rings THEN the eyballs appear and THEN kde rolls into 1920x10980
That's probably because you are not calling a second script in background. The screen is waiting for ~/.xprofile to finish. You have to detach the second script.
Yes, without having the sleep command, which the xeyes commands wait for, also in the background (executed asynchronously), then the whole startup process waits till after the sleep ends, and it defeats the purpose of using the sleep to try to run the xeyes at a later point in the process.
So you are suggesting (in .xprofile or other init script):
sleep_then_xeyes_script &
Yes.
An alternative that does the same thing, but without a separate script, is to put the commands in a sub-shell, run in the background:
( sleep 5 xeyes -geometry 70x50+36+420 & xeyes -geometry 70x50-36+420 & ) &
I am less familiar with this one, but yes. At worst, use the command "at" to have a delayed execution. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
Sun, 15 Dec 2024 09:34:40 +0000 (UTC) Robert Webb via openSUSE Users <users@lists.opensuse.org> :
An alternative that does the same thing, but without a separate script, is to put the commands in a sub-shell, run in the background:
( sleep 5 xeyes -geometry 70x50+36+420 & xeyes -geometry 70x50-36+420 & ) &
Applause, this one worked :-) I still don't know why there is a low-res screen though. No problem, in a few weeks it's a new motherboard AND a new GPU.
[was: All hail Robert Webb ..Re: 3 pairs of xeyes?] On Sun, 15 Dec 2024 22:27:27 -0500, bent fender <slowroller@trixtar.org> wrote:
Sun, 15 Dec 2024 09:34:40 +0000 (UTC) Robert Webb via openSUSE Users <users@lists.opensuse.org> :
An alternative that does the same thing, but without a separate script, is to put the commands in a sub-shell, run in the background:
( sleep 5 xeyes -geometry 70x50+36+420 & xeyes -geometry 70x50-36+420 & ) &
Applause, this one worked :-)
Thank you for the acknowledgment, but it was Carlos' idea to delay the xeyes with the sleep command. I just suggested the subshell to avoid needing a separate script, but if you were to put those commands in a script exactly as Carlos described, the result would be the same. Of course, there are multiple hacks here; the use of ~/.xprofile, the arbitrary delay. But who's complaining. :-)
I still don't know why there is a low-res screen though. No problem, in a few weeks it's a new motherboard AND a new GPU.
The desktop start up process is still too opaque to me to have a good idea how to track that down. But, since the sleep made the critical difference, it would be simple and interesting to see what processes changed in that time. Would you try replacing the 'sleep 5' command with the following code to get a 'ps' and a 'lsof' before and after the sleep?: XE_LOG_DIR="$HOME/log/xeyes" cough() { # usage: cough <subdir> local DLOG="$XE_LOG_DIR/${1:?}" mkdir -p "$DLOG" || exit ps -eo uid,pid,ppid,tname,args > "$DLOG"/ps 2>&1 lsof > "$DLOG"/lsof 2>&1 } cough a sleep 5 cough b Then, after logging in to the desktop, run these commands to upload the difference (post the susepaste URL): diff -r ~/log/xeyes/{a,b} > xeyes_delay.diff.txt susepaste -n Bent -t xeyes_delay.diff -f diff -e 151200 xeyes_delay.diff.txt -- Robert Webb
On 2024-12-13 02:42, bent fender wrote:
Tue, 10 Dec 2024 07:40:43 +0000 (UTC) Robert Webb via openSUSE Users <users@lists.opensuse.org> :
...
But Then I got THIS :-)))
I don't know what "-biblicallyAccurate" does but taking it out produces
The insertion still takes place on a lo0res screen and STAYS ant the lo-res screen X- coordinate when the screen goes hi-res. It doesn't look like .xprofil;e is being executed in a hi-res screen.
Try a delayed script?
I should maybe try to force the right pair to off screen by several hundred pixels on the right in the lo-res screen. When Carlos linked the syntax (which I've lost since!)
Archived-At: <https://lists.opensuse.org/archives/list/users@lists.opensuse.org/message/74IBMRPK7Q7KTTW6ZOI5QUTTU2SNLHGH/>
there was mention about the X going off screen if negative but I cannot figure that out because it already IS negative.
-- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
participants (4)
-
bent fender -
Carlos E. R. -
Masaru Nomiya -
Robert Webb