This repository has been archived by the owner on Feb 17, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 64
Mouse input is broken in all browsers #2
Comments
That was emscripten-core/emscripten#3060, which is fixed from emscripten 1.28.0 |
kripken
referenced
this issue
Jan 20, 2015
This issue is closed. Please, see emscripten-core/emscripten#3144 for further discussion. |
Daft-Freak
pushed a commit
that referenced
this issue
Oct 20, 2016
Robert Folland When running this little test program with SDL2 on Wayland it often crashes in SDL_Init. From a backtrace it is apparent that there is a race condition in creating a xkb_context_ref. Sometimes it is 0x0. By moving the relevant lines higher up in Wayland_VideoInit (in SDL2-2.0.4/src/video/wayland/SDL_waylandvideo.c:302) this seems to get fixed. I moved the call to WAYLAND_xkb_context_new() up to before the call to WAYLAND_wl_display_connect(). Here is the test program (just a loop of init and quit), and a backtrace from gdb: #include <cstdio> #include <stdlib.h> #include <SDL2/SDL.h> #include <unistd.h> #include <iostream> int main(int argc, char **argv) { int count = atoi(argv[1]); for (int i = 0; i < count; i++) { std::cout << "Init " << i << std::endl; if (SDL_Init(SDL_INIT_VIDEO) < 0) { SDL_LogError(SDL_LOG_CATEGORY_APPLICATION, "Couldn't initialize SDL: %s\n", SDL_GetError()); return 1; } std::cout << "Quit" << std::endl; SDL_Quit(); } return 0; } Init 12 Quit Init 13 Program received signal SIGSEGV, Segmentation fault. xkb_context_ref (ctx=ctx@entry=0x0) at src/context.c:156 156 ctx->refcnt++; (gdb) bt #0 xkb_context_ref (ctx=ctx@entry=0x0) at src/context.c:156 #1 0x00007ffff5e1cd4c in xkb_keymap_new (ctx=0x0, format=XKB_KEYMAP_FORMAT_TEXT_V1, flags=flags@entry=XKB_KEYMAP_COMPILE_NO_FLAGS) at src/keymap-priv.c:65 #2 0x00007ffff5e1c6cc in xkb_keymap_new_from_buffer (ctx=<optimized out>, buffer=0x7ffff7fd5000 "xkb_keymap {\nxkb_keycodes \"(unnamed)\" {\n\tminimum = 8;\n\tmaximum = 255;\n\t<ESC>", ' ' <repeats 16 times>, "= 9;\n\t<AE01>", ' ' <re peats 15 times>, "= 10;\n\t<AE02>", ' ' <repeats 15 times>, "= 11;\n\t<AE03>", ' ' <repeats 15 times>, "= 12;\n\t<AE04>", ' ' <repeats 12 times>..., length=48090, format=<optimized out>, flags=<optimized out>) at src/keymap.c:191 #3 0x00007ffff7b8ea4e in keyboard_handle_keymap (data=0x6169b0, keyboard=<optimized out>, format=<optimized out>, fd=5, size=48091) at /home/vlab/abs/sdl2/src/SDL2-2.0.4/src/video/wayland/SDL_waylandevents.c:269 #4 0x00007ffff64501f0 in ffi_call_unix64 () from /usr/lib/libffi.so.6 #5 0x00007ffff644fc58 in ffi_call () from /usr/lib/libffi.so.6 #6 0x00007ffff665be3e in wl_closure_invoke (closure=closure@entry=0x61f000, flags=flags@entry=1, target=<optimized out>, target@entry=0x616d20, opcode=opcode@entry=0, data=<optimized out>) at src/connection.c:949 #7 0x00007ffff6658be0 in dispatch_event (display=<optimized out>, queue=<optimized out>) at src/wayland-client.c:1274 #8 0x00007ffff6659db4 in dispatch_queue (queue=0x617398, display=0x6172d0) at src/wayland-client.c:1420 #9 wl_display_dispatch_queue_pending (display=0x6172d0, queue=0x617398) at src/wayland-client.c:1662 #10 0x00007ffff665a0cf in wl_display_roundtrip_queue (display=0x6172d0, queue=0x617398) at src/wayland-client.c:1085 #11 0x00007ffff7b8faa0 in Wayland_VideoInit (_this=<optimized out>) at /home/vlab/abs/sdl2/src/SDL2-2.0.4/src/video/wayland/SDL_waylandvideo.c:302 #12 0x00007ffff7b7aed6 in SDL_VideoInit_REAL (driver_name=<optimized out>, driver_name@entry=0x0) at /home/vlab/abs/sdl2/src/SDL2-2.0.4/src/video/SDL_video.c:513 #13 0x00007ffff7ae0ee7 in SDL_InitSubSystem_REAL (flags=16416) at /home/vlab/abs/sdl2/src/SDL2-2.0.4/src/SDL.c:173 #14 0x0000000000400b24 in main (argc=2, argv=0x7fffffffebb8) at vplay-init.cpp:13 (gdb)
Daft-Freak
pushed a commit
that referenced
this issue
Nov 4, 2017
…onitor setup w/ DPI scaling Eric Wasylishen 2017-07-26 18:42:58 UTC I set up an (admittedly exotic) 3-monitor setup, and when I enter fullscreen-desktop on the middle display (#2), the SDL window is off center. (covers half of monitor #2 and most of monitor #3). The displays are arranged from left to right: Display #1 (main): 2880x1800, 200% scaling Display #2: 1920x1200, 150% scaling Display #3: 1920x1080, 100% scaling SDL display bounds: INFO: Bounds: 1440x900 at 0,0 INFO: Bounds: 1281x801 at 1921,0 (these are incorrect) INFO: Bounds: 1920x1080 at 4800,0 Correct bounds reported by calling EnumDisplayMonitors and printing the LPRECT param of the callback: 1440x900 at (0, 0) 1280x800 at (2880, 0) 1920x1080 at (4800, 0) It seems like you need 3 displays to reproduce this, and the left two need DPI scaling, and the 3rd display needs to have a different scale factor than the others. Related: https://bugzilla.libsdl.org/show_bug.cgi?id=3709 SDL: current hg (11235:43c7baa53681) Windows 10, Version 10.0.15063 Build 15063 Tested with testdraw2 and testgl2, and pressing alt+enter to enter fullscreen desktop. This patch reworks SDL_windowsmodes.c to use EnumDisplayMonitors instead of EnumDisplayDevices, so we always have an HMONITOR for each SDL display. With access to an HMONITOR, we can get the monitor bounds in virtual screen coordinates the proper way, by calling GetMonitorInfo. (whereas the original code was doing some calculations - e.g. "data->DeviceMode.dmPosition.x * data->ScaleX" - to try to get virtual screen coordinates. These worked in simple cases, but failed in more complex cases like this bug) The one potential problem with my patch is, the ChangeDisplaySettingsEx docs say that you're supposed to get the display name from EnumDisplayDevices, but I'm getting the display name from GetMonitorInfo now.
jakogut
pushed a commit
to jakogut/SDL2
that referenced
this issue
Dec 3, 2019
Daft-Freak
pushed a commit
that referenced
this issue
May 7, 2021
Make sure the thread is actually paused, and context backep-up, before SurfaceView is destroyed (eg surfaceDestroyed() actually returns). Add a timeout when surfaceDestroyed() is called, and check 'backup_done' variable. It prevents crashes like: #00 pc 000000000000c0d0 /system/lib64/libutils.so (android::RefBase::incStrong(void const*) const+8) #1 pc 000000000000c7f4 /vendor/lib64/egl/eglSubDriverAndroid.so (EglAndroidWindowSurface::UpdateBufferList(ANativeWindowBuffer*)+284) #2 pc 000000000000c390 /vendor/lib64/egl/eglSubDriverAndroid.so (EglAndroidWindowSurface::DequeueBuffer()+240) #3 pc 000000000000bb10 /vendor/lib64/egl/eglSubDriverAndroid.so (EglAndroidWindowSurface::GetBuffer(EglSubResource*, EglMemoryDesc*)+64) #4 pc 000000000032732c /vendor/lib64/egl/libGLESv2_adreno.so (EglWindowSurface::UpdateResource(EsxContext*)+116) #5 pc 0000000000326dd0 /vendor/lib64/egl/libGLESv2_adreno.so (EglWindowSurface::GetResource(EsxContext*, EsxResource**, EsxResource**, int)+56) #6 pc 00000000002ae484 /vendor/lib64/egl/libGLESv2_adreno.so (EsxContext::AcquireBackBuffer(int)+364) #7 pc 0000000000249680 /vendor/lib64/egl/libGLESv2_adreno.so (EsxContext::Clear(unsigned int, unsigned int, unsigned int, EsxClearValues*)+1800) #8 pc 00000000002cb52c /vendor/lib64/egl/libGLESv2_adreno.so (EsxGlApiParamValidate::GlClear(EsxDispatch*, unsigned int)+132)
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
8d47621
This commit breaks input handling in all browsers.
See emscripten's
fillMouseEventData
. Pay attention to this line.Now it's executed with
target == document
, withgetBoundingClientRect
undefined.The text was updated successfully, but these errors were encountered: