xterm mouse pointer colour won't change
Environment: Ubuntu 10.04, gnome. After a couple of decades of running xterms with "-fg yellow -bg darkslategrey", I'm finding it harder to locate the mouse pointer when it's over text, even if I thrash the rat, to try to detect the motion. So I added "-ms red" to the xterm invocation. But that little I-like pointer remains white with a black border. I then tried putting this: *XTerm.pointerColor: red into ~/.Xdefaults , but it also had zero visible effect. Maybe it doesn't like red? Let's try: $ /usr/bin/xterm -bg darkslategrey -fg yellow -ms blue Nah. Humph. I'll try again tomorrow, I think. Erik -- Less is more or less more - Y_Plentyn on #LinuxGER
Erik Christiansen wrote:
Environment: Ubuntu 10.04, gnome.
After a couple of decades of running xterms with "-fg yellow -bg darkslategrey", I'm finding it harder to locate the mouse pointer when it's over text, even if I thrash the rat, to try to detect the motion. So I added "-ms red" to the xterm invocation. But that little I-like pointer remains white with a black border.
I then tried putting this:
*XTerm.pointerColor: red
into ~/.Xdefaults , but it also had zero visible effect.
Maybe it doesn't like red? Let's try:
$ /usr/bin/xterm -bg darkslategrey -fg yellow -ms blue
Nah. Humph. I'll try again tomorrow, I think.
Can you reproduce the issue WITHOUT gnome, i.e. xinit /usr/bin/xterm -ms red
On 21.03.12 11:49, Trent W. Buck wrote:
Erik Christiansen wrote:
So I added "-ms red" to the xterm invocation. But that little I-like pointer remains white with a black border.
Can you reproduce the issue WITHOUT gnome, i.e.
xinit /usr/bin/xterm -ms red
I'm googling on how to get that to work. Attempts thus far, to tickle xinit have not yet succeeded in getting it to try running an xterm: $ xinit /usr/bin/xterm -ms red X: user not authorized to run the X server, aborting. Apparently I can "fix" that by setting "allowed_users=anybody" in /etc/X11/Xwrapper.config, but let's just try: $ su - # xinit /usr/bin/xterm -ms red Fatal server error: Server is already active for display 0 If this server is no longer running, remove /tmp/.X0-lock and start again. Please consult the The X.Org Foundation support at http://wiki.x.org for help. ddxSigGiveUp: Closing log --------- There seems to be more crap here than I need, so I think I'll just go with the (ugh!) GUI work-around: Select Preferences->Mouse:Locate_Pointer Now widening circles appear around the pointer, on pressing the Control key. (Mind you, it now occurs to me that just holding down the left mouse key while dragging it about will highlight random swathes of the text in which the pointer is hiding, providing even greater visibility.) Incidentally, one google hit mentioned a bug in the Mint distro which caused "-ms" to do nothing. While that was a couple of years back, perhaps it's present in ubuntu as well. Erik -- What on earth would a man do with himself if something did not stand in his way? - H.G. Wells
Erik Christiansen <dvalin@internode.on.net> wrote:
$ su - # xinit /usr/bin/xterm -ms red
Fatal server error: Server is already active for display 0 If this server is no longer running, remove /tmp/.X0-lock and start again.
If you had an X session running when you did this, you should have switched to a virtual console and shut down the X server temporarily. It seems that you solved the original problem satisfactorily, however.
Erik Christiansen wrote:
$ xinit /usr/bin/xterm -ms red
X: user not authorized to run the X server, aborting.
By default, you are only allowed to start X if 1) you're root; or 2) you're logged in at the console (i.e. tty1 through ttyN). As you say, this can be turned off:
Apparently I can "fix" that by setting "allowed_users=anybody" in /etc/X11/Xwrapper.config
...but you should avoid doing so unless you understand the risks.
$ su - # xinit /usr/bin/xterm -ms red
Fatal server error: Server is already active for display 0
This is, of course, because you already have an X server running on the default port (:0, or 7000 in TCP terms). Either turn off X (probably log out of X and then "sudo /etc/init.d/gdm stop"), or create a second X server: xinit /usr/bin/xterm -ms red -- /usr/bin/Xorg :1
Incidentally, one google hit mentioned a bug in the Mint distro which caused "-ms" to do nothing. While that was a couple of years back, perhaps it's present in ubuntu as well.
I can't comment on that unless you cite the URL.
On 21.03.12 19:09, Trent W. Buck wrote:
xinit /usr/bin/xterm -ms red -- /usr/bin/Xorg :1
Thanks for that, Trent. There also, the pointer fails to acquire any colour. It does seem that xterm does not honour the option.
Incidentally, one google hit mentioned a bug in the Mint distro which caused "-ms" to do nothing. While that was a couple of years back, perhaps it's present in ubuntu as well.
I can't comment on that unless you cite the URL.
It was only a passing observation which I hadn't researched in depth. A quick check, now, for "xterm -ms" on ubuntu's launchpad site showed no full matches. But then, google doesn't seem to find a "-ms" either, so I think I'll just go back to what I'm trying to achieve, rather than futz any more. Thanks again for your insight. Erik -- Gods don't like people not doing much work. People who aren't busy all the time might start to _think_. - Terry Pratchett, "Small Gods"
On 21 March 2012 19:54, Erik Christiansen <dvalin@internode.on.net> wrote:
It was only a passing observation which I hadn't researched in depth. A quick check, now, for "xterm -ms" on ubuntu's launchpad site showed no full matches. But then, google doesn't seem to find a "-ms" either, so I think I'll just go back to what I'm trying to achieve, rather than futz any more.
I have the same results, and I use ratpoison, not Gnome. Looking at the source code for xterm, I see this function: void recolor_cursor(TScreen * screen, Cursor cursor, /* X cursor ID to set */ unsigned long fg, /* pixel indexes to look up */ unsigned long bg) /* pixel indexes to look up */ { Display *dpy = screen->display; XColor colordefs[2]; /* 0 is foreground, 1 is background */ colordefs[0].pixel = fg; colordefs[1].pixel = bg; XQueryColors(dpy, DefaultColormap(dpy, DefaultScreen(dpy)), colordefs, 2); XRecolorCursor(dpy, cursor, colordefs, colordefs + 1); return; } Am guessing that maybe something in xorg has changed to break XRecolorCursor. However this page would imply it should still work: http://www.justlinux.com/nhf/X_Window/Custom_Cursors.htm -- Brian May <brian@microcomaustralia.com.au>
Erik Christiansen wrote:
On 21.03.12 19:09, Trent W. Buck wrote:
xinit /usr/bin/xterm -ms red -- /usr/bin/Xorg :1
Thanks for that, Trent. There also, the pointer fails to acquire any colour. It does seem that xterm does not honour the option.
Is "red" in your /etc/X11/rgb.txt? (I'm pretty sure the names are case-insensitive).
On 22 March 2012 11:32, Trent W. Buck <trentbuck@gmail.com> wrote:
Is "red" in your /etc/X11/rgb.txt? (I'm pretty sure the names are case-insensitive).
It is in mine. -- Brian May <brian@microcomaustralia.com.au>
On 22 March 2012 15:36, Brian May <brian@microcomaustralia.com.au> wrote:
On 22 March 2012 11:32, Trent W. Buck <trentbuck@gmail.com> wrote:
Is "red" in your /etc/X11/rgb.txt? (I'm pretty sure the names are case-insensitive).
It is in mine.
Also: brian@aquitard:~$ xterm -ms dddd Warning: Color name "dddd" is not defined brian@aquitard:~$ xterm -ms red brian@aquitard:~$ -- Brian May <brian@microcomaustralia.com.au>
On Tue, 20 Mar 2012 23:06:53 +1100, Erik Christiansen <dvalin@internode.on.net> wrote:
After a couple of decades of running xterms with "-fg yellow -bg darkslategrey", I'm finding it harder to locate the mouse pointer when it's over text, even if I thrash the rat, to try to detect the motion. So I added "-ms red" to the xterm invocation. But that little I-like pointer remains white with a black border.
I can also replicate this behaviour on Debian. On two machines running Debian Squeeze (stable) and another running Debian Wheezy (testing), the '-ms' flag of xterm appears to have no effect. These machines all have gdm3 installed, and are running a reasonably default Gnome desktop. Even if I shutdown the desktop and windows manager, and run xterm on these machines on a plain X server, the mouse pointer color is not affected by the flag. However, on my own desktop, which is also running Debian Squeeze, but has no display manager and uses fluxbox as the window manager, the '-ms' flag works as expected (setting the inner color of the mouse pointer). If I ssh into one of the machines that doesn't work as expected (ie, piping X over ssh to my own desktop X server), the remotely running term is stuck with a white cursor, even though its display window is on X on my local desktop. Whereas if I run an term on another Debian machine (again X over ssh) that has no X server installed, I can set the color of the xterm mouse pointer, again the display window on my local desktop. Glenn -- pool.sks-keyservers.net 0xb1e82ec9228ac090
On Thu, 22 Mar 2012 04:39:14 pm Glenn McIntosh wrote:
On Tue, 20 Mar 2012 23:06:53 +1100, Erik Christiansen <dvalin@internode.on.net> wrote:
After a couple of decades of running xterms with "-fg yellow -bg darkslategrey", I'm finding it harder to locate the mouse pointer when it's over text, even if I thrash the rat, to try to detect the motion. So I added "-ms red" to the xterm invocation. But that little I-like pointer remains white with a black border.
I can also replicate this behaviour on Debian.
On two machines running Debian Squeeze (stable) and another running Debian Wheezy (testing), the '-ms' flag of xterm appears to have no effect. These machines all have gdm3 installed, and are running a reasonably default Gnome desktop.
It is stubbornly red on my machine but this is because of the X resources in the server: $ xrdb -q|grep cursorColor XTerm*cursorColor: red I can change the colour with xterm -xrm 'XTerm*cursorColor: green' but not xterm -xrm '*cursorColor: green' -- Anthony Shipman Mamas don't let your babies als@iinet.net.au grow up to be outsourced.
On Thu, 22 Mar 2012 18:17:37 +1100, Anthony Shipman <als@iinet.net.au> wrote:
It is stubbornly red on my machine but this is because of the X resources in the server: $ xrdb -q|grep cursorColor XTerm*cursorColor: red
The text cursor (cursorColor) and the mouse cursor (pointerColor) are handled separately. Compare: xterm -cr blue xterm -ms blue Glenn -- pool.sks-keyservers.net 0xb1e82ec9228ac090
On Thu, 22 Mar 2012 07:19:37 pm Glenn McIntosh wrote:
On Thu, 22 Mar 2012 18:17:37 +1100, Anthony Shipman <als@iinet.net.au> wrote:
It is stubbornly red on my machine but this is because of the X resources in the server: $ xrdb -q|grep cursorColor XTerm*cursorColor: red
The text cursor (cursorColor) and the mouse cursor (pointerColor) are handled separately. Compare: xterm -cr blue xterm -ms blue
Oops, my bad. Here's something more. The behaviour on my machine with Centos6.2 and nvidia depends on the cursor shape e.g. I can do xterm -ms red -xrm 'XTerm*pointerShape: gumby' -xrm 'XTerm*pointerColorBackground: green' and get red and green in the pointer, similarly for the shape 'iron_cross'. The colour is ignored for the shapes xterm (the I beam) and hand1, hand2 and fleur. You can find a list of cursor shapes in /usr/include/X11/cursorfont.h The libXcursor package may have an effect on the implementation of cursors. -- Anthony Shipman Mamas don't let your babies als@iinet.net.au grow up to be outsourced.
On 22 March 2012 20:39, Anthony Shipman <als@iinet.net.au> wrote:
and get red and green in the pointer, similarly for the shape 'iron_cross'. The colour is ignored for the shapes xterm (the I beam) and hand1, hand2 and fleur.
Interesting was wondering if the cursor itself was the problem.
You can find a list of cursor shapes in /usr/include/X11/cursorfont.h
The libXcursor package may have an effect on the implementation of cursors.
My wild speculation is that cursors were initially designed with 3 (maybe 4 colours) - bg, fg, transparent (and maybe reverse transparent). These work with the XRecolorCursor X call that xterm uses. Then one day they enhanced the format to support more colours, and in doing so broke the XRecolorCursor X call. -- Brian May <brian@microcomaustralia.com.au>
On 22.03.12 16:39, Glenn McIntosh wrote:
However, on my own desktop, which is also running Debian Squeeze, but has no display manager and uses fluxbox as the window manager, the '-ms' flag works as expected (setting the inner color of the mouse pointer).
Ah, that's interesting ... and yes, on my laptop with Debian 6.0 and LXDE, "-ms" works fine. It might be time to log a bug report with Ubuntu, even if it might not be sufficiently GUI-sexy to warrant a high priority there. Erik -- "Those who live by the GUI, die by the GUI" - Duncan Roe, on luv-main ML.
Glenn McIntosh wrote:
On Tue, 20 Mar 2012 23:06:53 +1100, Erik Christiansen <dvalin@internode.on.net> wrote:
After a couple of decades of running xterms with "-fg yellow -bg darkslategrey", I'm finding it harder to locate the mouse pointer when it's over text, even if I thrash the rat, to try to detect the motion. So I added "-ms red" to the xterm invocation. But that little I-like pointer remains white with a black border.
I can also replicate this behaviour on Debian.
On two machines running Debian Squeeze (stable) and another running Debian Wheezy (testing), the '-ms' flag of xterm appears to have no effect. These machines all have gdm3 installed, and are running a reasonably default Gnome desktop.
Even if I shutdown the desktop and windows manager, and run xterm on these machines on a plain X server, the mouse pointer color is not affected by the flag.
However, on my own desktop, which is also running Debian Squeeze, but has no display manager and uses fluxbox as the window manager, the '-ms' flag works as expected (setting the inner color of the mouse pointer).
I cannot reproduce this issue with xinit /usr/bin/xterm -ms cyan -cr magenta -fg yellow -bg black on oneric (don't ask), without gdm or any other dm installed. I see a cyan I-bar with a black border around it (due to because -bg black). This (obviously) only affects the pointer while it is over the xterm; outside of there it is the default fat "X" shape. However I reckon I just worked out what it is. X pointers are now themable, and I expect you have an X pointer theme installed. Since they're PNGs (with alpha transparency, whoop-de-doo!) you can't just set fg/bg colours of the pointer while they're on. Once upon a time I had notes on how to customize that; I can't find them now. Back then, IIRC, they were customized host-wide via update-alternatives; I notice from apt-file that GTK3 appears to also have per-theme pointers now in /usr/share/icons/Adwaita/cursors.
On Fri, 23 Mar 2012 11:50:37 +1100, Trent W. Buck <trentbuck@gmail.com> wrote:
However I reckon I just worked out what it is. X pointers are now themable, and I expect you have an X pointer theme installed. Since they're PNGs (with alpha transparency, whoop-de-doo!) you can't just set fg/bg colours of the pointer while they're on.
You've nailed it. The dmz-cursor-theme is brought in by default in Squeeze if packages such as evolution and gnome-screensaver are installed (which are part of the default desktop). If I install dmz-cursor-theme then I can no longer change my cursor colors, since it now uses the image files. The theme name is defined in /usr/share/icons/default/index.theme so the original color behaviour can be restored simply by commenting out the 'Inherits' parameter from that file. Glenn -- pool.sks-keyservers.net 0xb1e82ec9228ac090
participants (6)
-
Anthony Shipman -
Brian May -
Erik Christiansen -
Glenn McIntosh -
Jason White -
Trent W. Buck