Closed matanox closed 1 year ago
matanox
commented
1 year ago A small and very hypothetical comment: in the rare case that this is because the active window for key presses is changed when calling .close() on another window, I think it is possibly asymmetric to how the opengl context is managed, whereby you need to call .switch_to() on a window to explicitly switch the drawing context to it.
caffeinepills
commented
1 year ago Tested on Windows and output is expected with one key press and release.
on_key_press 115 0
closing other window
other window closed
on_key_release 115 0It is most likely some specific Linux issue.
pushfoo
commented
1 year ago I can replicate this on the development branch. I'm on Debian 11 with Gnome + Wayland.
$ python -m pyglet.info
Platform
------------------------------------------------------------------------------
platform: Linux-5.10.0-23-amd64-x86_64-with-glibc2.31
release: 5.10.0-23-amd64
machine: x86_64
Python
------------------------------------------------------------------------------
implementation: CPython
sys.version: 3.9.2 (default, Feb 28 2021, 17:03:44)
[GCC 10.2.1 20210110]
sys.maxint: 9223372036854775807
os.getcwd(): /home/user/src/pyglet
pyglet
------------------------------------------------------------------------------
pyglet.version: 2.0.8
pyglet.compat_platform: linux
pyglet.__file__: /home/user/src/pyglet/pyglet/__init__.py
pyglet.options['audio'] = ('xaudio2', 'directsound', 'openal', 'pulse', 'silent')
pyglet.options['debug_font'] = False
pyglet.options['debug_gl'] = True
pyglet.options['debug_gl_trace'] = False
pyglet.options['debug_gl_trace_args'] = False
pyglet.options['debug_gl_shaders'] = False
pyglet.options['debug_graphics_batch'] = False
pyglet.options['debug_lib'] = False
pyglet.options['debug_media'] = False
pyglet.options['debug_texture'] = False
pyglet.options['debug_trace'] = False
pyglet.options['debug_trace_args'] = False
pyglet.options['debug_trace_depth'] = 1
pyglet.options['debug_trace_flush'] = True
pyglet.options['debug_win32'] = False
pyglet.options['debug_input'] = False
pyglet.options['debug_x11'] = False
pyglet.options['shadow_window'] = True
pyglet.options['vsync'] = None
pyglet.options['xsync'] = True
pyglet.options['xlib_fullscreen_override_redirect'] = False
pyglet.options['search_local_libs'] = True
pyglet.options['win32_gdi_font'] = False
pyglet.options['scale_with_dpi'] = False
pyglet.options['headless'] = False
pyglet.options['headless_device'] = 0
pyglet.options['win32_disable_shaping'] = False
pyglet.options['dw_legacy_naming'] = False
pyglet.options['win32_disable_xinput'] = False
pyglet.options['com_mta'] = False
pyglet.options['osx_alt_loop'] = False
pyglet.window
------------------------------------------------------------------------------
display: <pyglet.display.xlib.XlibDisplay object at 0x7f123ced4370>
screens[0]: XlibScreen(display=<pyglet.display.xlib.XlibDisplay object at 0x7f123ced4370>, x=1920, y=0, width=1920, height=1080, xinerama=True)
screens[1]: XlibScreen(display=<pyglet.display.xlib.XlibDisplay object at 0x7f123ced4370>, x=0, y=0, width=1920, height=1080, xinerama=True)
config['double_buffer'] = 1
config['stereo'] = 0
config['buffer_size'] = 24
config['aux_buffers'] = 0
config['sample_buffers'] = 0
config['samples'] = 0
config['red_size'] = 8
config['green_size'] = 8
config['blue_size'] = 8
config['alpha_size'] = 0
config['depth_size'] = 24
config['stencil_size'] = 0
config['accum_red_size'] = 0
config['accum_green_size'] = 0
config['accum_blue_size'] = 0
config['accum_alpha_size'] = 0
config['major_version'] = 3
config['minor_version'] = 3
config['forward_compatible'] = None
config['opengl_api'] = 'gl'
config['debug'] = None
context: XlibContext(id=139716322897728, share=XlibContext(id=139716308322096, share=None))
window.context._info
------------------------------------------------------------------------------
gl_info.get_version(): (4, 6)
gl_info.get_vendor(): Intel
gl_info.get_renderer(): Mesa Intel(R) UHD Graphics 620 (KBL GT2)
pyglet.gl.glx_info
------------------------------------------------------------------------------
context.is_direct(): 1
glx_info.get_server_vendor(): SGI
glx_info.get_server_version(): 1.4
glx_info.get_server_extensions():
GLX_ARB_context_flush_control
GLX_ARB_create_context
GLX_ARB_create_context_no_error
GLX_ARB_create_context_profile
GLX_ARB_fbconfig_float
GLX_ARB_framebuffer_sRGB
GLX_ARB_multisample
GLX_EXT_create_context_es_profile
GLX_EXT_create_context_es2_profile
GLX_EXT_fbconfig_packed_float
GLX_EXT_framebuffer_sRGB
GLX_EXT_import_context
GLX_EXT_libglvnd
GLX_EXT_no_config_context
GLX_EXT_texture_from_pixmap
GLX_EXT_visual_info
GLX_EXT_visual_rating
GLX_MESA_copy_sub_buffer
GLX_OML_swap_method
GLX_SGI_make_current_read
GLX_SGIS_multisample
GLX_SGIX_fbconfig
GLX_SGIX_pbuffer
GLX_SGIX_visual_select_group
glx_info.get_client_vendor(): Mesa Project and SGI
glx_info.get_client_version(): 1.4
glx_info.get_client_extensions():
GLX_ARB_context_flush_control
GLX_ARB_create_context
GLX_ARB_create_context_no_error
GLX_ARB_create_context_profile
GLX_ARB_create_context_robustness
GLX_ARB_fbconfig_float
GLX_ARB_framebuffer_sRGB
GLX_ARB_get_proc_address
GLX_ARB_multisample
GLX_EXT_buffer_age
GLX_EXT_create_context_es2_profile
GLX_EXT_create_context_es_profile
GLX_EXT_fbconfig_packed_float
GLX_EXT_framebuffer_sRGB
GLX_EXT_import_context
GLX_EXT_swap_control
GLX_EXT_swap_control_tear
GLX_EXT_texture_from_pixmap
GLX_EXT_visual_info
GLX_EXT_visual_rating
GLX_INTEL_swap_event
GLX_MESA_copy_sub_buffer
GLX_MESA_multithread_makecurrent
GLX_MESA_query_renderer
GLX_MESA_swap_control
GLX_OML_swap_method
GLX_OML_sync_control
GLX_SGIS_multisample
GLX_SGIX_fbconfig
GLX_SGIX_pbuffer
GLX_SGIX_visual_select_group
GLX_SGI_make_current_read
GLX_SGI_swap_control
GLX_SGI_video_sync
glx_info.get_extensions():
GLX_ARB_create_context
GLX_ARB_create_context_no_error
GLX_ARB_create_context_profile
GLX_ARB_fbconfig_float
GLX_ARB_framebuffer_sRGB
GLX_ARB_get_proc_address
GLX_ARB_multisample
GLX_EXT_buffer_age
GLX_EXT_create_context_es2_profile
GLX_EXT_create_context_es_profile
GLX_EXT_fbconfig_packed_float
GLX_EXT_framebuffer_sRGB
GLX_EXT_import_context
GLX_EXT_swap_control
GLX_EXT_swap_control_tear
GLX_EXT_texture_from_pixmap
GLX_EXT_visual_info
GLX_EXT_visual_rating
GLX_MESA_copy_sub_buffer
GLX_MESA_query_renderer
GLX_MESA_swap_control
GLX_OML_swap_method
GLX_OML_sync_control
GLX_SGIS_multisample
GLX_SGIX_fbconfig
GLX_SGIX_pbuffer
GLX_SGIX_visual_select_group
GLX_SGI_make_current_read
GLX_SGI_video_sync
pyglet.media
------------------------------------------------------------------------------
audio driver: <pyglet.media.drivers.openal.adaptation.OpenALDriver object at 0x7f123cf62e80>
pyglet.media.ffmpeg
------------------------------------------------------------------------------
FFmpeg version: 4.3.6-0+deb11u1
pyglet.media.drivers.openal
------------------------------------------------------------------------------
Library: <CDLL 'libopenal.so.1', handle 11fdd80 at 0x7f123cea73d0>
Version: 1.1
Extensions:
ALC_ENUMERATE_ALL_EXT
ALC_ENUMERATION_EXT
ALC_EXT_CAPTURE
ALC_EXT_DEDICATED
ALC_EXT_disconnect
ALC_EXT_EFX
ALC_EXT_thread_local_context
ALC_SOFT_device_clock
ALC_SOFT_HRTF
ALC_SOFT_loopback
ALC_SOFT_output_limiter
ALC_SOFT_pause_device
pyglet.input.wintab
------------------------------------------------------------------------------
WinTab not available.Huge thanks for the replication efforts @pushfoo @caffeinepills I'm using X11 and Gnome 3.36.8, not wayland, forgot to check before. I wonder what can it be.
pushfoo
commented
1 year ago It may be X-related since I'm pretty sure I'm running via Wayland's X compatibility. I'm not sure how to check at the moment.
matanox
commented
1 year ago The issue is actually a little bit broader. Replace closing the window by just making it not visible as in the code below, and you get the exact same problem (at least on the same machine, not necessarily on other platforms).
""" Minimaly Reproducible Keyboard Events Issue, posted at https://github.com/pyglet/pyglet/issues/911 """
import time
import pyglet
from pyglet.window import Window
class KeyboardEventsIssue():
def _register_window_callbacks(self, window):
def update(dt):
# self.window2.switch_to()
# update processing related to main window
time.sleep(0.001)
# self.window.switch_to()
# update processing related to other window
@window.event
def on_draw():
# self.window2.switch_to()
# draw other window
time.sleep(0.001)
# self.window.switch_to()
# draw other window
@window.event
def on_key_press(symbol, modifiers):
print('on_key_press', symbol, modifiers)
time.sleep(0.2)
print('setting other window invisible')
self.window2.set_visible(False)
print('other window invisible')
@window.event
def on_key_release(symbol, modifiers):
print('on_key_release', symbol, modifiers)
return update
def __init__(self):
self.window = Window(width=1280, height=720, resizable=True)
self.window2 = Window(width=720, height=720, resizable=True)
self.update_callback = self._register_window_callbacks(self.window)
pyglet.clock.schedule_interval(self.update_callback, 1/30)
pyglet.app.event_loop.run()
if __name__ == '__main__':
KeyboardEventsIssue()The key release is swallowed same as before, and on the next key press of the same key, you get a release event and not a 'press` event (same as before).
matanox
commented
1 year ago Narrowing it down a little, the described abnormal behavior takes place when there is sufficient busy time between starting to handle the key press event and between set_visible(False). I.e. remove the sleep inside the press callback, and the key events happen as you would expect them.
Of course, being busy for the same duration rather than sleeping, has the same effect:
start_busy = time.time()
while time.time() - start_busy < 0.2:
passThe amount of time being busy within the key press callback prior to .set_visible(False) determines whether the irregularity will happen or not.
matanox
commented
1 year ago And we also get the same exact behavior if the second window is initialized not visible, and then turned visible inside the key press callback:
""" Minimaly Reproducible Keyboard Events Issue, posted at https://github.com/pyglet/pyglet/issues/911 """
import time
import pyglet
from pyglet.window import Window
class KeyboardEventsIssue():
def _register_window_callbacks(self, window):
def update(dt):
# self.window2.switch_to()
# update processing related to main window
time.sleep(0.001)
# self.window.switch_to()
# update processing related to other window
@window.event
def on_draw():
# self.window2.switch_to()
# draw other window
time.sleep(0.001)
# self.window.switch_to()
# draw other window
@window.event
def on_key_press(symbol, modifiers):
print('on_key_press', symbol, modifiers)
time.sleep(0.2)
self.window2.set_visible(True)
@window.event
def on_key_release(symbol, modifiers):
print('on_key_release', symbol, modifiers)
return update
def __init__(self):
self.window = Window(width=1280, height=720, resizable=True)
self.window2 = Window(width=720, height=720, resizable=True, visible=False)
self.update_callback = self._register_window_callbacks(self.window)
pyglet.clock.schedule_interval(self.update_callback, 1/30)
pyglet.app.event_loop.run()
if __name__ == '__main__':
KeyboardEventsIssue()Further, even if we remove our key release callback from this code, we will still get abnormal behavior ― the second time we press the same keyboard key, we will not get our key press callback called.
This is all when it is the same key pressed a first time and then a second time ― if the second key pressed is different, everything is normal.
benmoran56
commented
1 year ago Same behavior on XWayland and Xorg. In your original example, If you press and release the key very slowly, it functions as expected.
I'm not sure if this is a bug in pyglet, or a limitation in xlib.
pushfoo
commented
1 year ago If sleep freezes the process entirely, maybe they block input handling as well. What happens if you use other filler code instead of sleep?
matanox
commented
1 year ago @pushfoo as mentioned a tight loop like follows maintains the exact same behavior
start_busy = time.time()
while time.time() - start_busy < 0.2:
passWhile Xlib is still widely deployed I would guess, it is well known that its design is quite something of the past and even though my application is plagued by this, I would vote to not try to fix it, unless it's something obvious in how pyglet is using Xlib. I haven't found any documented bug description about this for Xlib myself, I know Xlib has this notion of key grabs which may relate but I wouldn't know. X11 architecture is, no offense, a little convoluted (or overly complex) compared to how you would imagine key handling. Maybe I'm wrong.
At least the issue is well understood now as having a very well-defined and very specific impact, it's not something wide about key handling but constrained to a particular subset and situation that may only hurt some application design flows.
benmoran56
commented
1 year ago I couldn't find any obvious places on the pyglet side where we might be missing events.
This code should be the "lowest" level of our interaction with xlib events: https://github.com/pyglet/pyglet/blob/master/pyglet/canvas/xlib.py#L152
I did some debug prints, and the key up/down events (2, 3) do not appear to be coming through.
matanox
commented
1 year ago Switching to reuse the windows side-steps the matter completely insofar. Thanks for all your comments and thank you for pyglet.
matanox
commented
11 months ago Thanks again for your past support on this solved issue.
As I approach upgrading the Ubuntu distribution that our pyglet project supports, I am just happy to learn if there is anything built into pyglet for logging whether the system is using Wayland v.s. X11 and/or the gnome version, as these aspects have made small yet pertinent differences before in terms of support.
I'm not aware it is part of python -m pyglet.info at least not in pyglet 2.0.5, and maybe it's not even straightforward to detect in python at all.
benmoran56
commented
11 months ago @matanster pyglet itself doesn't have that information. I'm not sure if it's possible to query from xlib or not, but we're not currently checking. XWayland probably does it's best to appear as a "normal" X server, so it may be difficult.
If it's set, you can query the XDG session type. IE:
>>> os.environ.get('XDG_SESSION_TYPE', 'unknown')
'wayland'Thanks for bothering to respond on this fringe aspect! indeed that line yields the output x11 on my system (as opposed to your wayland output), so it may be indeed useful!
matanox
commented
6 months ago This equally manifests every time when a key press leads to the opening of an external window, e.g. a browser window opened via a webbrowser.open().
The pyglet application loses focus to the browser, which yields the same behavior as described.
At least on my Ubuntu 22.04 on Wayland. The workaround is the same ― act on the event only on its key release event.
Description
In a multi-window pyglet application, when a key press event callback calls user code closing a pyglet window, the key release event for that key will queue until the same key is pressed again.
How to Reproduce
releaseevent will fire instead of apressevent.The output on my machine:
then nothing happens, and only when the same key is pressed again:
System Information
Ubuntu 20.04.