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

After SDL 1.2.14 update, wesnoth doesn't accept mouse clicks in windowed mode #533

Closed
SDLBugzilla opened this issue Feb 10, 2021 · 0 comments

Comments

@SDLBugzilla
Copy link
Collaborator

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: 1.2.14
Reported for operating system, platform: Linux, Other

Comments on the original bug report:

On 2009-11-26 08:23:26 +0000, Bernhard Rosenkraenzer wrote:

When using SDL 1.2.14, wesnoth (http://wesnoth.org/) doesn't accept mouse clicks when running in windowed mode on Linux.

Going back to SDL 1.2.13 "fixes" the problem.

Wesnoth bug report (resolved as "upstream problem"):
https://gna.org/bugs/index.php?14770

On 2009-12-11 07:18:33 +0000, Sam Lantinga wrote:

I haven't seen any problems with SDL mouse clicks on Linux. Does anyone have more information on what's going on?

In the original bug report, the originator mentions he seems to be the only one to have the problem:
http://forum.wesnoth.org/viewtopic.php?f=4&t=27800&start=0

On 2009-12-24 06:51:51 +0000, pillz wrote:

Problem has been reported at the Arch forums as well, with many users experiencing it. Again, downgrading to sdl 1.2.13 solved it.

I can't really provide any details, wesnoth doesn't seem to be giving out any errors. All I can say is this: it just doesn't accept left mouse clicks in windowed mode (unless you are holding down the right mouse button at the same time, or the ctrl key). No problems in fullscreen mode.

Like the original comment in here said, Wesnoth's devs have labeled it an upstream problem..

http://bbs.archlinux.org/viewtopic.php?id=83675

On 2010-03-23 03:52:02 +0000, Nils Kneuper wrote:

Please make sure to monitor the updates in the Wesnoth bugtracker. As listed in there it does depend on the windowmanager used and the problems do not occur in fullscreen mode. In general you do get this warning in the beta versions (default log level is reduced to error again in final 1.8):

20100323 11:46:49 warning gui/event: distributor mouse button left [wml_message_left]: SDL left button up. The mouse button is already up, we missed an event.

So it looks like some strange stuff is going on with the click events. Yes, this warning only occurs when using libsdl 1.2.14. This is on KDE 4.x where things mostly work, all I have to do every now and then is activate another application and then go back to Wesnoth and clicking does work in this Window Manager. Other WMs are affected a lot more. All the info about this is available in the Wesnoth bugtracker at https://gna.org/bugs/index.php?14770 . It would be really good if this bug was fixed eventually since I would love to remove this warning about libsdl being broken in those regards from the Wesnoth release announcement. Even worse, the next Ubuntu LTS series is likely to ship with this problematic libsdl release...

On 2010-03-23 04:06:42 +0000, Nils Kneuper wrote:

Some more info:
If you want to get those warnings shown start wesnoth this was:
wesnoth --log-error=all
Once in a campaign you should get many of the messages I mentioned since the new gui dialogs do somehow still work when only receiving the mouse up event. Here is what mordante wrote in the related Debian bug report ([1]) about the way Wesnoth does use libsdl click events:

"The problem is that after the upgrade the buttons in the user interface no longer work. Clicking with the mouse on a button in the main menu does nothing at all, rendering Wesnoth completely unusable. I did some testing and it seems the widgets only receive a mouse button up event and no mouse button down event. The Wesnoth engine expects both events before registering a click on the widget."

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565788

On 2010-03-23 04:08:25 +0000, Nils Kneuper wrote:

(In reply to comment # 4)

Some more info:
If you want to get those warnings shown start wesnoth this was:
wesnoth --log-error=all

Sorry, wrong one:

wesnoth --log-warnings=all

On 2010-04-08 11:29:22 +0000, Nils Kneuper wrote:

A patch fixing this issue was posted in the debian bug tracker at [1]. A Wesnoth dev (who was affected by the issue) tested the patch and reports that it does fix it for him. It would be great if there was a 1.2.15 release fixing this issue.

[1]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565788# 19

On 2010-04-20 03:51:37 +0000, Nils Kneuper wrote:

To have some crosslinking between the reports:
The fix in the debian bugtracker does partly revert the fix for bug # 716. So it looks like the fix for this problem caused a (IMO quite bad!) regression. It would be really great if you could have a look at this.

On 2010-06-04 01:59:59 +0000, Remko Bijker wrote:

(In reply to comment # 6)

A patch fixing this issue was posted in the debian bug tracker at [1].
[1]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565788# 19

Please note that this patch breaks OpenTTD. This is described and fixed in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578389

On 2010-07-18 10:44:49 +0000, Sam Lantinga wrote:

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

On 2010-07-19 22:45:10 +0000, Sam Lantinga wrote:

FYI, I finally got a configuration where I can reproduce this bug. It looks like when you click the mouse under fvwm you get this sequence of events:

LeaveNotify event, serial 34, synthetic NO, window 0x4a00001,
root 0xa3, subw 0x0, time 171216347, (144,119), root:(170,211),
mode NotifyGrab, detail NotifyAncestor, same_screen YES,
focus YES, state 272

EnterNotify event, serial 34, synthetic NO, window 0x4a00001,
root 0xa3, subw 0x0, time 171216347, (144,119), root:(170,211),
mode NotifyUngrab, detail NotifyAncestor, same_screen YES,
focus YES, state 272

KeymapNotify event, serial 34, synthetic NO, window 0x0,
keys: 4294967203 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

ButtonPress event, serial 34, synthetic NO, window 0x4a00001,
root 0xa3, subw 0x0, time 171216347, (144,119), root:(170,211),
state 0x10, button 1, same_screen YES

ButtonRelease event, serial 34, synthetic NO, window 0x4a00001,
root 0xa3, subw 0x0, time 171216767, (144,119), root:(170,211),
state 0x110, button 1, same_screen YES

This is all legal, even if it's a little weird, so I'm downloading Wesnoth to see why it's complaining about this sequence of events. It's a little big, so it's going to take a while. :)

On 2010-07-20 00:10:30 +0000, Sam Lantinga wrote:

Okay, once I was able to reproduce this, I was able to get a good fix without breaking the previous bug 716.

This is fixed in revision 4aa31b9207f2. I'm attaching a patch relative to vanilla SDL 1.2.14.

Thanks!

On 2010-07-20 00:18:08 +0000, Sam Lantinga wrote:

Okay, I verified that this fix takes care of both Wesnoth and OpenTTD.

Woot! :)

On 2010-07-20 00:18:52 +0000, Sam Lantinga wrote:

Created attachment 524
Patch relative to vanilla SDL 1.2.14

On 2011-11-01 11:33:12 +0000, Alan Swanson wrote:

Could we please have this applied to the SDL-1.2 branch too?

On 2011-11-01 11:43:24 +0000, Alan Swanson wrote:

Hmm, looks like my hg pulls haven't been updating all files properly. Sorry for the noise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant