Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wacom Tablet support #4376

Closed
wants to merge 3 commits into from
Closed

Wacom Tablet support #4376

wants to merge 3 commits into from

Conversation

david-polak
Copy link

Hi,

I have just started learning LMMS and found it quite difficult to control the Knobs with my Wacom pen tablet. I use my tablet to alleviate RSI strain of using the mouse, and have gotten quite used to it.

Unfortunately, the current implementation of the Knob is incompatible with a tablet set to Absolute mode (pixels on tablet are mapped roughly 1:1 to pixels on screen). Since in Knob::mouseMoveEvent

QCursor::setPos( mapToGlobal( m_origMousePos ) );

the cursor position gets reset, which then triggers a new QMouseEvent because now the cursor position is far away from the current tablet position (which is absolute). First I tried to hack the existing code, but my effort has proven fruitless, due to the nature of the Knob mouse handling implementation (though, I couldn't figure out a better way to do it either)

So I have implemented the TabletEvent interface. Any events that aren't handled by the new code get
event->ignore()ed and then Qt spawns a regular QMouseEvent which then propagates as usual.

So far, Knob is the only GUI element which I found that behaved strangely with my tablet, I will add support to any other elements if I find them.

@josh-audio
Copy link
Member

I see you're using tablet-specific Qt events. Does the mouse behavior remain the same?

@david-polak
Copy link
Author

Yes, QMouseEvent is unaffected in any way.

When QTabletEvent is not handled and not accepted, Qt generates a QMouseEvent.
When the actual mouse is the originator no QTabletEvent is generated and everything is handled the standard way. I haven't touched the mouse handling logic at all.

@david-polak
Copy link
Author

I just reread my code, another commit incoming. Need to fix the tabletRelease handler

@josh-audio
Copy link
Member

Alright, awesome. I will model the vector graph tension handles (#4367) after that. Would you be willing to test it if I ping you about it in maybe a week or so?

@david-polak
Copy link
Author

Does it need special handling for tablet support? Can you send me instructions how to test your current working version?

@josh-audio
Copy link
Member

Clone/build the branch, add the plug-in ”Waveshaper 2” to the master effects chain, and try to drag the little circle in the middle of the line. I've implemented that functionality in a similar way to the knob dragging so I expect it to break in a similar way. I can just ping you when I have a fix implemented.

@ghost
Copy link

ghost commented May 27, 2018

What tablet are you using and which driver version?

I agree that there are problems with tablets but I'm not seeing your issue with my particular tablet. I have other issues with my tablet. (intuos, driver: 6.3.29-6)

Try raising the value of the knob with your stylus, hold it, check the value while holding the stylus motionless, then lower it while looking at the value. What I'm seeing on my end is that for a brief moment the value increases when going down with the stylus. It is as if the motion was buffered (it hadn't processed the final moments in its buffer of the stylus going upwards).

Does my explanation make any sense?
Do you also have this "delay" with your tablet?

@david-polak
Copy link
Author

Interesting, what OS are you using, I am using Arch Linux, will check the tablet version when I get to my pc?

Do you have the tablet in absolute mode? I could see this issue not being present if the driver actually stops giving updates when you are not moving, but the linux driver I am using does not behave like that.

Have you tried building and running with my branch? Does it affect your issue?

@PhysSong
Copy link
Member

There are some situations where QCursor::setPos is called:

  • Resizing track height (shift + click and drag, called when resizing starts)
  • Drawing graph out of the boundary
  • Tweaking knob (the original problem)
  • Changing value of LCD spin box (e.g. changing pitch range by click and vertical drag)

@PhysSong
Copy link
Member

PhysSong commented Aug 7, 2018

Just a question: can we remove unnecessary and/or problematic calls to setPos instead?

@Reflexe Reflexe added the response required A response from OP is required or the issue is closed automatically within 14 days. label May 27, 2019
@PhysSong
Copy link
Member

Due to the conflicts of #5360, it makes no sense to merge this as-is.
@JohannesLorenz @tresf Any ideas on this PR? I'm asking you because this looks similar to #5194 in some sense.

@JohannesLorenz
Copy link
Contributor

I think even if we rewrite this PR correctly concerning setPos, it does not make sense to test it without #5360 . This would mean we first have to

  1. Merge Fix #5194: Fix knobs moving too fast #5360 to stable-1.2
  2. Merge stable-1.2 to master
  3. Rebase this PR to master

@PhysSong
Copy link
Member

PhysSong commented Jun 4, 2020

#5360 fixed the issue, so I'm closing this.

@PhysSong PhysSong closed this Jun 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
response required A response from OP is required or the issue is closed automatically within 14 days.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants