5

I have just upgraded my ubuntu (Ubuntu 18.04.2 LTS, bionic). I am using xcalib -i -a to reverse the colors of my screen. Unfortunately, since the upgrade, something seems to have broken: xcalib stops working at random (and this is a little nightmare for my eyes). I don't really know which information is relevant for this question. Here are the last modules installed (obtained with : find /var/lib/dpkg/info/ -name \*.list -mtime -3 | sed 's#.list$##;s#.*/##' ) :

libmng2:amd64
libnss-systemd:amd64
libgimp2.0
libkf5kdelibs4support-data
libpam-systemd:amd64
systemd
pciutils
libbabl-0.1-0:amd64
libkf5kdelibs4support5:amd64
systemd-sysv
libgegl-0.3-0:amd64
libnss-myhostname:amd64
libsystemd0:amd64
libcurl4:amd64
libpci3:amd64
libudev1:amd64
libkf5sane-data
libcogl20:amd64
libkf5sane5
libcogl-pango20:amd64
gir1.2-coglpango-1.0:amd64
libkf5kdelibs4support5-bin
gir1.2-cogl-1.0:amd64
gdm3
initramfs-tools
initramfs-tools-core
initramfs-tools-bin
libgdm1
libcogl-common
gir1.2-gdm-1.0
libcogl-path20:amd64
libcurl3-gnutls:amd64
gnome-software-plugin-snap
libvulkan1:amd64
gnome-software
gnome-software-common
ubuntu-software

If someone has an idea, I would really appreciate. A little detail : when xcalib stops, I run it again with a shortcut of mine and it stops immediately again. When I use again the shortcut, it waits approximately one minute to stop again. :(

Thanks in advance.


Edit 23/02/2019 : the problem did not disappear, and this is still a nightmare. :( :( :( I'm starting to loose hope. I removed and reinstalled xcalib, with no effect of course. Right now, I am trying to see which processes appear (in top) when I keep changing the color of the screen.

Potentially linked due to activity : irq/71-brcmf_pc (by the way, I have a mac with Ubuntu installed on it, I should have precised that from the start ; this is my professional laptop, I couldn't choose :[ ), iio-sensor-prox, colord, gsd-xsettings, gsd-media-keys, gsd-clipboard, at-spi2-registr.

I had a look on the internet to see what these processes were doing, but I have not a single clue. So, I start a bounty.


Edit 01/03/2019 : The problem occurred again, but this time, thanks to Sam Wheel and his command line ( tail -f /var/log/syslog ), I managed to capture the problematic process. Here is a sample of what precisely occurred when xcalib stopped :

Mar  1 01:31:14 Synia dhclient[7120]: DHCPREQUEST of ***.***.19.90 on ens9 to ***.***.64.51 port 67 (xid=0x5bce959f)
Mar  1 01:34:18 Synia dhclient[7120]: message repeated 15 times: [ DHCPREQUEST of ***.***.19.90 on ens9 to ***.***.64.51 port 67 (xid=0x5bce959f)]

After what I set xcalib again :

Mar  1 01:34:38 Synia /usr/lib/gdm3/gdm-x-session[1341]: (II) modeset(0): EDID vendor "APP", prod id 41001
Mar  1 01:34:38 Synia /usr/lib/gdm3/gdm-x-session[1341]: (II) modeset(0): Printing DDC gathered Modelines:
Mar  1 01:34:38 Synia /usr/lib/gdm3/gdm-x-session[1341]: (II) modeset(0): Modeline "2560x1600"x0.0  268.50  2560 2608 2640 2720  1600 1603 1609 1646 +hsync -vsync (98.7 kHz eP)

And the DHCP request continues, over and over again, with the same effect on xcalib :

Mar  1 01:34:39 Synia dhclient[7120]: DHCPREQUEST of ***.***.19.90 on ens9 to ***.***.64.51 port 67 (xid=0x5bce959f)
Mar  1 01:35:55 Synia dhclient[7120]: message repeated 6 times: [ DHCPREQUEST of ***.***.19.90 on ens9 to ***.***.64.51 port 67 (xid=0x5bce959f)]    

Mar  1 01:36:09 Synia dhclient[7120]: DHCPREQUEST of ***.***.19.90 on ens9 to ***.***.64.51 port 67 (xid=0x5bce959f)
Mar  1 01:36:47 Synia dhclient[7120]: message repeated 3 times: [ DHCPREQUEST of ***.***.19.90 on ens9 to ***.***.64.51 port 67 (xid=0x5bce959f)]

etc.

At some point (10 minutes later), I also had a DHCPACK :

Mar  1 01:44:03 Synia dhclient[7120]: DHCPREQUEST of ***.***.19.90 on ens9 to ***.***.64.51 port 67 (xid=0x5bce959f)
Mar  1 01:44:31 Synia dhclient[7120]: message repeated 3 times: [ DHCPREQUEST of ***.***.19.90 on ens9 to ***.***.64.51 port 67 (xid=0x5bce959f)]
Mar  1 01:44:50 Synia dhclient[7120]: DHCPREQUEST of ***.***.19.90 on ens9 to 255.255.255.255 port 67 (xid=0x5bce959f)
Mar  1 01:44:50 Synia dhclient[7120]: DHCPACK of ***.***.19.90 from ***.***.19.81
Mar  1 01:44:50 Synia NetworkManager[858]: <info>  [1551401090.2999] dhcp4 (ens9):   address ***.***.19.90
Mar  1 01:44:50 Synia NetworkManager[858]: <info>  [1551401090.2999] dhcp4 (ens9):   plen 28 (255.255.255.240)
Mar  1 01:44:50 Synia NetworkManager[858]: <info>  [1551401090.3000] dhcp4 (ens9):   gateway ***.***.19.81
Mar  1 01:44:50 Synia NetworkManager[858]: <info>  [1551401090.3000] dhcp4 (ens9):   lease time 1800
Mar  1 01:44:50 Synia NetworkManager[858]: <info>  [1551401090.3000] dhcp4 (ens9):   hostname 'mb27'
Mar  1 01:44:50 Synia NetworkManager[858]: <info>  [1551401090.3000] dhcp4 (ens9):   nameserver '***.***.32.40'
Mar  1 01:44:50 Synia NetworkManager[858]: <info>  [1551401090.3000] dhcp4 (ens9):   nameserver '***.***.222.4'
Mar  1 01:44:50 Synia NetworkManager[858]: <info>  [1551401090.3000] dhcp4 (ens9):   domain name 'mg09.***.**'
Mar  1 01:44:50 Synia dbus-daemon[811]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' requested by ':1.11' (uid=0 pid=858 comm="/usr/sbin/NetworkManager --no-daemon " label="unconfined")
Mar  1 01:44:50 Synia NetworkManager[858]: <info>  [1551401090.3000] dhcp4 (ens9): state changed bound -> bound
Mar  1 01:44:50 Synia systemd[1]: Starting Network Manager Script Dispatcher Service...
Mar  1 01:44:50 Synia dbus-daemon[811]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Mar  1 01:44:50 Synia systemd[1]: Started Network Manager Script Dispatcher Service.
Mar  1 01:44:50 Synia nm-dispatcher: req:1 'dhcp4-change' [ens9]: new request (1 scripts)
Mar  1 01:44:50 Synia nm-dispatcher: req:1 'dhcp4-change' [ens9]: start running ordered scripts...
Mar  1 01:44:50 Synia dhclient[7120]: bound to ***.***.19.90 -- renewal in 846 seconds.

This seems thus to be a DHCP request that prevents xcalib from working correctly (at least, the "randomness" is explained). No idea what this is precisely (I see that everything happens on the port 67 which is used, amongst others, by Apple NetBoot ; since I have a Mac with dual boot Linux-Mac, could it be linked by means of some firmware ?). I also precise that I have a special cable that has its own IP to connect to my network (a Mac device).

Any suggestions ?


Edit 02/03/2019 : New day, new problem (it always occurs around midnight, seemingly). This time, the log gives another problem :

Error: Error invoking IBus.set_global_engine_async: Expected function for callback argument callback, got undefined#012setEngine@resource:///org/gnome/shell/misc/ibusManager.js:207:9#012wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22#012activateInputSource@resource:///org/gnome/shell/ui/status/keyboard.js:490:13#012wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22#012_emit@resource:///org/gnome/gjs/modules/signals.js:128:27#012activate@resource:///org/gnome/shell/ui/status/keyboard.js:65:9#012wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22#012_inputSourcesChanged@resource:///org/gnome/shell/ui/status/keyboard.js:620:13#012wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22#012reload@resource:///org/gnome/shell/ui/status/keyboard.js:369:9#012wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22#012_ibusSetContentType@resource:///org/gnome/shell/ui/status/keyboard.js:691:9#012wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22#012_emit@resource:///org/gnome/gjs/modules/signals.js:128:27#012_setContentType@resource:///org/gnome/shell/misc/ibusManager.js:183:9#012wrapper@resource:///org/gnome/gjs/modules/_legacy.js:82:22

Apart from this novelty, this is the same problem as yesterday. I'll try the solutions given by sancho.s tomorrow morning (the first one was not successful so far).

  • Strangely, the problem solved itself yesterday after an update... Still no explanation of which process was problematic. Nevertheless, these new packages were added : 'libisccfg160:amd64 libisccc160:amd64 libirs160:amd64 libdns1100:amd64 libisc169:amd64 liblwres160:amd64 ' – Synia Feb 22 at 11:40
  • Well, I was too optimistic. It's still there. And I don't believe it will go away by pure magic. – Synia Feb 23 at 1:07
  • 1
    Try looking at logs by entering following cmd in terminal window and show what error occurs when it happens: tail -f /var/log/syslog – Sam Wheel Feb 26 at 9:45
  • Thanks a lot for the command. I am waiting for it again. The word "at random" in the title makes plainly sense. It only happened once again, when I closed the lid of my laptop, and I was unable to track down the process. – Synia Feb 28 at 14:06
  • I'm assuming you require xcalib because your eyes are sensitive to white or nearly white backgrounds. If that is correct, with a little trouble you can find dark themes or dark settings for most applications. And, though this is just my opinion, using dark themes/settings is visually more satisfying. – DK Bose Mar 1 at 12:33
1

You may try resetting values to their default with

xcalib -c

Clearly, this precludes using xcalib for what you mean, but it may help in getting rid of the problem and/or diagnosing it.

You may also try alternative ways to control screen output, with xrandr and other commands, which may even have some advantages ("... use xrandr instead of xcalib since, among other limitations, the latter doesn't provide a proper way to query its state.") See

https://askubuntu.com/a/401845/226614

https://www.reddit.com/r/linux/comments/27b0k0/xrandr_and_screen_color_inversion_setting_is_fine/

For your specific use, see

Easiest way to invert colors on Ubuntu 18.04

Admittedly, I am not providing an answer to What is the problem?, but the request is If someone has an idea, I would really appreciate

  • Thanks for your suggestions. Indeed, the solution is maybe to switch to another program. Zoltan Padrah's program seems to be a good alternative (this is the only use I have of xcalib). I also used your command xcalib -c and it resulted in killing the night mode. :P But I had this problem before I became aware of the existence of the night mode (well, this could still be related, but I now believe this is a DHCP request that triggers that). – Synia Mar 1 at 11:10
  • @Synia - Well, that is what xcalib -c does... Please post feedback if you try some of the alternatives here. – sancho.s Mar 1 at 16:55
  • Right now, this is becoming crazy again, so I am using all your solutions one by one. I can already tell that the first one gives unfortunately nothing. I have the following problem xrandr: Need crtc to set gamma on. – Synia Mar 1 at 23:09
  • @Synia - Which is the first one? What do you mean by "gives unfortunately nothing"? Do you get only that message? Googling suggests that it is a problem possibly related to drivers+hardware+kernel+versions. Please post exactly what you are doing and what you get. – sancho.s Mar 2 at 10:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.