Skip to content

Conversation

@kasper93
Copy link
Member

@kasper93 kasper93 commented Mar 3, 2025

They still can be remapped individually by users, but let's duplicate them by default.

Same as 8c6ad1d.
Fixes: #15993

@github-actions
Copy link

github-actions bot commented Mar 3, 2025

Download the artifacts for this pull request:

Windows
macOS

@zhongfly
Copy link

zhongfly commented Mar 3, 2025

How about KP_ENTER keypress ENTER ?

@kasper93
Copy link
Member Author

kasper93 commented Mar 3, 2025

how about KP_ENTER keypress ENTER ?

Hmm, maybe. Not sure what looks better if you read this file or something like stats.lua.

@kasper93 kasper93 force-pushed the input_conf branch 2 times, most recently from 12e9cc6 to 722bb5d Compare March 3, 2025 15:28
@kasper93
Copy link
Member Author

kasper93 commented Mar 3, 2025

@na-na-hi thoughts?

@zhongfly
Copy link

zhongfly commented Mar 3, 2025

keypress does not work for keys bound to repeatable commands.
Example: KP_MULTIPLY keypress * does not work like KP_MULTIPLY add volume 2, only add volume 2 once.

Is it possible to add a flag for keypress so that one key can be exactly equivalent to another?

@na-na-hi
Copy link
Contributor

na-na-hi commented Mar 3, 2025

keypress has the repeatability problem. Default repeatability depends on the command, and keypress is not repeatable by default, so it's wrong if the command on the mapped key is repeatable. If you force it with the repeatable prefix, it would behave wrong if the command on the mapped key is not repeatable.

Also keypress only sends the press event but not the down/up/repeat event, so when a script uses mp.add_key_binding it cannot know which state the key is in, so it behaves differently from real keypresses.

@kasper93
Copy link
Member Author

kasper93 commented Mar 3, 2025

So, I don't know what to do here. I don't want to manually duplicate everything. It pollutes input config. And doing this in core would probably be even worse. We could add some sort of aliasing mechanism, but it seems too much for this case alone.

@eNV25
Copy link

eNV25 commented Mar 3, 2025

The default behavior of keypress could changed so that it's repeatable if possible, else normal i.e. no error. The repeatable and nonrepeatable can be used to control it if needed.

@eNV25
Copy link

eNV25 commented Mar 3, 2025

For the keypad arrow keys repeatable keypress is the only one that works, since many scripts (like console.lua, etc.) add bindings to the normal arrow keys dynamically.

@kasper93 kasper93 force-pushed the input_conf branch 2 times, most recently from 723a7b1 to 7dd5ddf Compare March 3, 2025 16:55
@kasper93
Copy link
Member Author

kasper93 commented Mar 3, 2025

changed it back to using commands directly.

They still can be remapped individually by users, but let's duplicate
them by default.

Same as 8c6ad1d.

Fixes: mpv-player#15993
@hooke007
Copy link
Contributor

hooke007 commented Mar 4, 2025

Q: Is it possible to improve the syntax?

For instance:

RIGHT   seek 5
DOWN   seek 5
KP_RIGHT   seek 5
KP_DOWN   seek 5
d   seek 5
s   seek 5
k   seek 5
j   seek 5

Use the de-duplicated solutions:

RIGHT,DOWN,KP_RIGHT,KP_DOWN,d,s,k,j   seek 5

@kasper93
Copy link
Member Author

kasper93 commented Mar 4, 2025

It's probably possible, but not sure the cosmetic gain is enough to justify to parser change. Though it shouldn't be a big one.

@eNV25
Copy link

eNV25 commented Mar 4, 2025

This doesn't actually fix the linked issue completely, since it doesn't touch console.lua and other built-in scripts.

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

Successfully merging this pull request may close these issues.

No key binding found for arrows keys on Windows tablet keyboard

5 participants