GNOME Bugzilla – Bug 780375
Color picker won't pick on Wayland
Last modified: 2018-05-24 17:37:31 UTC
Ever since I'm using GIMP on Wayland, which came with Fedora 25, I cannot pick colours anymore. Neither in the image itself, nor from system windows.
Right, we need a wayland picking backend for GimpPickButton, just like we have one for the screenshot plug-in. But this won't happen in 2.8.
Mitch > is it a 2.10 blocker in your opinion? Or can we move it for a 2.10.x/3.0 milestone?
Not a blocker, but quite a joke to implement (I think), keep it on 2.10 for now so I don't forget about it, we can always move it to 3.0 later.
Andy, what happens when you try? Are there any warnings printed when you start GIMP from the terminal?
It'll pick black #000000 no matter where I click. When starting I'm getting some messages, but not when picking a colour: lcms: converting from 'sRGB IEC61966-2-1 black scaled' to 'sRGB built-in' While parsing XMP metadata: Fehler: Es wurde kein XMP-Paket gefunden lcms: skipping conversion because profiles seem to be equal: sRGB IEC61966-2.1 sRGB built-in While parsing XMP metadata: Fehler in Zeile 11 Zeichen 1: Das Ende von Element <xmpMM:DerivedFrom> wurde in diesem Zusammenhang nicht erwartet Metadata parasite seems to be corrupt lcms: skipping conversion because profiles seem to be equal: sRGB IEC61966-2.1 sRGB built-in
I have the same problem on Ubuntu 17.10 with Wayland. If at login I choose 'ubuntu default' (x11) then color picker works fine. I have the same messages starting gimp in x11 or in wayland: corrado@corrado-HP-art2:~$ gimp (gimp:4921): GLib-GObject-WARNING **: g_object_set_is_valid_property: object class 'GeglConfig' has no property named 'cache-size' corrado@corrado-HP-art2:~$
Those are the bugs filed downstream for this problem: Ubuntu --> https://bugs.launchpad.net/ubuntu/+source/gimp/+bug/1705188 Fedora --> https://ask.fedoraproject.org/en/question/99480/cannot-pick-a-color-with-gimp-color-picker/ Fedora switched to Wayland by default with Fedora 25, Ubuntu will follow suit with Ubuntu 17.10 in October, probably shipping Gimp 2.8.x. Everybody using Gimp will run into this bug (color picking seems very common), so I would consider backporting the fix to the 2.8 branch as well. It regresses the workflow in a very annoying way and people well not know that this is a problem due to the (hidden) Wayland switch.
Thx @amano. Fedora does not track bugs on the ask platform, but I found these related bug reports: Program colorpicker crashes in wayland but not in x.org https://bugzilla.redhat.com/show_bug.cgi?id=1399344 colour pickers (several tried) not working on Wayland session https://bugzilla.redhat.com/show_bug.cgi?id=1342286 (gpick) Any plan to use gtk3 for Wayland support? https://github.com/thezbyg/gpick/issues/133
Gpick is gtk2. Right? It won't work on wayland. Even with gtk3 it requires significant changes from wayland side which is very unlikely to happen in any foreseeable future knowing their attitude. So in short no gimp on wayland. :/
but gnome-screenshot and Keyboard shortcut Prt Scrn works fine
Because there is a screenshot API in gnome-shell, but no color picking API for individual pixels.
I can confirm this issue is currently present in Gimp 2.8.20 on Ubuntu 17.10 Wayland session, GNOME 3.26.1
Pushed a partial solution to master: instead of always picking from the root window, which we can't do on Wayland, try to first pick from the local window under the cursor, which is still possible. This at least allows us to pick colors from local windows on Wayland. Even if we add some Wayland magic later on, this might still be more efficient in the local-window case. commit 0323541d869620836b8cbf034e728989416fbdff Author: Ell <ell_se@yahoo.com> Date: Tue Oct 31 11:13:44 2017 -0400 Bug 780375 - Color picker won't pick on Wayland In GimpPickButton, try to pick from the local window under the cursor, before falling back to picking from the root window, so that we can at least pick from local windows on Wayland. libgimpwidgets/gimppickbutton-default.c | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-)
I am the developer of a small color picking application for a GNOME3 desktop, gcolor3[1]. Naturally, I hit this issue as well. I just opened https://bugzilla.gnome.org/show_bug.cgi?id=789756 in the hopes to discuss a solution for all applications dealing with this; please take a look and add anything that GIMP requires to the discussion as well, thanks! [1]: https://github.com/Hjdskes/gcolor3/
Since the API does not even exist yet on GNOME or other Wayland-based desktop, this is not going to happen that soon. No need to expect it will be for 2.10 which we want very soon. Pushing to 2.12, hoping the API exists by then.
Putting back to 2.10 milestone. We decided to simply put the very import bugs as blockers. Anything non-blocker have simply very few chances to make it unless someone decides to give it an importance (by working on it and providing working patches).
KDE already supports color picking in wayland. https://phabricator.kde.org/D3481
(In reply to xpetept from comment #17) > KDE already supports color picking in wayland. > https://phabricator.kde.org/D3481 Thanks! From the code I read, and from this other link I found (https://phabricator.kde.org/D3480), this dbus API returns a QColor, which is a Qt/C++, as far as I can tell. How can we get the picked color in a C/non-Qt application? Do I miss something.
For information I just sent an email to the author of this dbus API. Hoping to get an answer on how to make usage of this API/return value!
We should definitely implement a picking backend for KDE too, but in order to make this work on GNOME/wayland, gnome-shell needs to implement a similar API, like it does for screenshots.
(In reply to Michael Natterer from comment #20) > in order to make this work on GNOME/wayland, gnome-shell needs > to implement a similar API, like it does for screenshots. Cf. bug 789756. This looks like it may not exist by the time we release 2.10. :-/ About the KDE API, the answer from the developer of the API dbus on KDE: > I just used bustle to see what is actually transmitted and it looks like a 32 bit ARGB value. > It transmits @(u) (4293980400,) and the picked color is F0F0F0. > > We only use QColor as it's convenient for our usage. The actual transport happens through a DBus conversion. So that should be fairly easy to implement on our side. I'll have a look.
Setting this as blocker since there is already the KDE API. So we should at least implement it for KDE.
Jadahl, can you add something like that to Mutter?
Wouldn't better to do the same thing KWin is doing instead of using the KDE API. I mean accessing wayland directly. This way it would work in any desktop enviroment.
An app has no rights to pick anywhere from screen, only the compositor has, that's why it has to go through the window manager.
I have implemented it and I believe this should work, except that their color-picking method is apparently broken. It's not just my code, even calling the dbus method from the d-feet application for instance returns the same error. So I opened a bug report at KDE's: https://bugs.kde.org/show_bug.cgi?id=387720 I still push the code because to prevent bitrot. In any case, I added a fallback to the default color picking when the KDE one fails so that we won't have regression for KDE/X11. commit 06bbf3e4369433d0d2c78963a7b1da2674d01460 (HEAD -> master, origin/master, origin/HEAD) Author: Jehan <jehan@girinstud.io> Date: Fri Dec 8 23:32:45 2017 +0100 Bug 780375 - Color picker won't pick on Wayland. Add support for KWin API, for KDE on Wayland. Unfortunately though, KWin's "pick" API seems to have failures, so I fallback to the default color picking when this happens. This will still not work on Wayland, but at least won't cause regression for color picking on KDE/X11. See also KDE bug: https://bugs.kde.org/show_bug.cgi?id=387720 libgimpwidgets/Makefile.am | 2 +- libgimpwidgets/gimppickbutton-kwin.c | 115 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ libgimpwidgets/gimppickbutton.c | 17 +++++++++----- 3 files changed, 127 insertions(+), 7 deletions(-)
Apparently the version packaged in Fedora 27 is old and unmaintained and probably has some bugs (cf. bug report on KDE side). I believe my implementation should work anyway on KDE/Wayland. As for GNOME, it has no implementation yet, so nothing can be done. So let's keep this report opened but there is no need to keep it as a blocker for 2.10. Setting back to normal.
Still same problem with Gimp 2.10 in Ubuntu 18.10 Cosmic
(In reply to corrado venturini from comment #28) > Still same problem with Gimp 2.10 in Ubuntu 18.10 Cosmic Which desktop? As said in the current report, for GNOME, this is normal: GNOME does not provide an API for color-picking yet, so there is nothing we can do in a sandboxed world without an official API. See bug 789756. As for KDE, they have an API, but it was failing on X11. They fixed it (cf. comment 26) but not sure if that fix already made it to distributions.
corrado@corrado-p9-cc-0506:~$ inxi -SCGx System: Host: corrado-p9-cc-0506 Kernel: 4.15.0-20-generic x86_64 bits: 64 compiler: gcc v: 7.3.0 Desktop: Gnome 3.28.1 Distro: Ubuntu Cosmic CANIMAL (development branch) CPU: Topology: Dual Core model: Intel Core i3-7100 bits: 64 type: MT MCP arch: Skylake rev: 9 L2 cache: 3072 KiB flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 31296 Speed: 801 MHz min/max: 800/3900 MHz Core speeds (MHz): 1: 800 2: 800 3: 800 4: 800 Graphics: Card-1: Intel HD Graphics 630 driver: i915 v: kernel bus ID: 00:02.0 Display: x11 server: X.Org 1.19.6 driver: i915 resolution: 1920x1080~60Hz OpenGL: renderer: Mesa DRI Intel HD Graphics 630 (Kaby Lake GT2) v: 4.5 Mesa 18.0.2 direct render: Yes corrado@corrado-p9-cc-0506:~$
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/1074.