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).
