Someone who is familiar with wayland should do that. I'm not using gnome or wayland myself at this point. Not that libinput has problems anyway -- it causes irregular lines.

Does this issue affect Krita under KDE's Wayland implementation? 

I'd really rather not have to choose between GNOME and Krita at some point in the future. For the moment, it's not the only app with some issues on Wayland, but it is the only one I use that's completely unusable there at the moment.

Probably, but I don't know. I haven't got a wayland setup, so, like I said before, someone who cares about wayland should start working on making Krita work on Wayland. I'm not that person. Just telling me that Krita is completely unusable on Wayland doesn't convince me to change my priorities: you can always stop using Wayland and use X11 instead.

I don't understand. Are you saying that you're the only person presently working on Krita, and that Krita is not targeting Wayland in the foreseeable future? Because that's an answer to both the original question and mine. 

I didn't question (or mention) anyone's priorities, but perhaps I was a bit unclear in distinguishing the two separate possibilities I was considering there. If this was exclusively a GNOME problem, that'd be unfortunate from my perspective. If it was a Krita / Wayland problem, I would have guessed that someone would have been looking into it, but I'm not making an argument for that here, I simply assumed that would probably be the case. I do also understand that Wayland support in KDE Plasma is just now becoming available, while it's beginning to be the default in GNOME systems. 

In any case, so far as I can tell, tablet input does not seem to function at all through xwayland in GNOME (the pointer disappears when it enters a xwayland app and moves the window if dragged), and Krita appears to be running as an xwayland window. 

I'm well aware that I can just use X, which is (naturally) how I'm using Krita at present.

I'm not the only person working on Krita, but there's nobody who is working on Krita who has a wayland system. If people want krita to work on Wayland, they have to do the work to make Krita work on Wayland; until there is someone who cares both about wayland and about krita, no work will happen.

I am, more or less, the only developer regularly checking bugzilla. I don't use wayland, not with kwin, not with gnome; wayland right now is something that might be relevant in the future, it's not relevant right now. Nobody is going to make better art, or make art quicker, or have more fun making art because their system is using wayland: that means that people who care about wayland need to do work.

Again, I don't think I'm arguing with your priorities, and it sounds like Wayland support will come when it becomes necessary (at some juncture after some number of those developers are using Wayland systems.) I can understand why something that's still somewhat prospective like this isn't a priority for a fairly small development team. In any case, thanks for the information.

If I can humbly add my voice, for me Wayland is the way to go to finally have a correct touch support in Krita under Linux, and that's useful in term of user interaction. But I fully understand that's not a priority right now.

Good news, Krita 4.1 is almost working with Wayland on Ubuntu 18.04.

Stylus works, touch gestures are working, I only miss Rotation support for the Wacom Art Pen (see bug 396409). 
Maybe the borders of drawing strokes are a little too sharp using Wayland.
Boud, can you explain us what is the status of Wyaland support in Krita ?

Thanks in advance,
Camille

Um... We never did anything related to wayland, at all. We never received any patches from Wayland fans for krita. There has been no code written for wayland support at all. Krita directly links to X11 libraries on Linux, unconditionally, and uses xcb to get tablet events. That means that if you run Krita in a wayland sessions, it uses the X11 compatibility layer, whatever it is called. If that layer doesn't forward rotation events, then there's nothing we can do.

We still need a wayland fan to step up and implement tablet support; that code might then be upstreamed to Qt, which doesn't have tablet support under Wayland either.

*** Bug 396409 has been marked as a duplicate of this bug. ***

OK, it works so well I through your worked in it !
I just warned Peter Hutterer you need help, but I don't know if he can spare time for that, even if I hope so ;)

For reference libinput issue is here: https://gitlab.freedesktop.org/libinput/libinput/issues/76

From what I can tell, rotation is forwarded just fine through XWayland so I still suspect that the issue is Krita or at least X-client side. Could there be some assumption about the axis ranges, numbering or somesuch?

I'm not even totally sure about that. There is some remapping from axes, though.

Hi, Peter!

For both, art-pen stylus rotation and airbrush side-pressure switch we use valuator with XCB atom "Abs Wheel". 

# atoms we use
"Abs X\0"
"Abs Y\0"
"Abs Pressure\0"
"Abs Tilt X\0"
"Abs Tilt Y\0"
"Abs Wheel\0"

# code, that uses them:
        int valuator = it.key();
        TabletData::ValuatorClassInfo &classInfo(it.value());
        xi2GetValuatorValueIfSet(event, classInfo.number, &classInfo.curVal);
        double normalizedValue = (classInfo.curVal - classInfo.minVal) / (classInfo.maxVal - classInfo.minVal);
        switch (valuator) {
        case QXcbAtom::AbsPressure:
            pressure = normalizedValue;
            break;
        case QXcbAtom::AbsTiltX:
            xTilt = classInfo.curVal;
            break;
        case QXcbAtom::AbsTiltY:
            yTilt = classInfo.curVal;
            break;
        case QXcbAtom::AbsWheel:
            switch (tabletData->tool) {
            case QTabletEvent::Airbrush:
                tangentialPressure = normalizedValue * 2.0 - 1.0; // Convert 0..1 range to -1..+1 range
                break;
            case QTabletEvent::RotationStylus:
                rotation = normalizedValue * 360.0 - 180.0; // Convert 0..1 range to -180..+180 degrees
                break;
            default:    // Other types of styli do not use this valuator
                break;
            }
            break;
        default:
            break;
        }

Basically, if wayland's XCB compatibility layer implements valuators with these atoms, then Krita starts handling it

I think I should resolve this bug as upstream now. I have added the notes what Wayland people should do to let Krita use rotational sensor, so we need to just wait for them to implement it in libinput.

Apologies for the delay, this slipped through.

>  art-pen stylus rotation and airbrush side-pressure switch  we use valuator with XCB atom "Abs Wheel". 

Quick check of the xf86-input-libinput source code: the airbrush slider is initialized with "Abs Throttle" and the artpen rotation from this bug report is "Abs Rotary Z".
I suggest adding those to the Krita code - the reason for the mismatch is that the xf86-input-wacom driver didn't set up tools on demand, so multiple different things shared one axis label. That's for when you're running on pure X, not Wayland, and you're using the xf86-input-libinput driver instead of the wacom driver for tablets.

As for Xwayland, it seems to set the atoms equivalent to the wacom driver, and the axis ranges as well. so I'm not sure why this doesn't work. Afaict the code is all there.

Paul: what does xinput test-xi2 say when you use the pen and rotate it?