summaryrefslogtreecommitdiffstats
path: root/mpvcore/input/input.h
Commit message (Collapse)AuthorAgeFilesLines
* Move mpvcore/input/ to input/wm42013-12-171-303/+0
|
* input: move some command flags into a bitfieldwm42013-12-161-4/+9
|
* Add prelimimary (basic, possibly broken) dvdnav supportwm42013-12-121-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | This readds a more or less completely new dvdnav implementation, though it's based on the code from before commit 41fbcee. Note that this is rather basic, and might be broken or not quite usable in many cases. Most importantly, navigation highlights are not correctly implemented. This would require changes in the FFmpeg dvdsub decoder (to apply a different internal CLUT), so supporting it is not really possible right now. And in fact, I don't think I ever want to support it, because it's a very small gain for a lot of work. Instead, mpv will display fake highlights, which are an approximate bounding box around the real highlights. Some things like mouse input or switching audio/subtitles stream using the dvdnav VM are not supported. Might be quite fragile on transitions: if dvdnav initiates a transition, and doesn't give us enough mpeg data to initialize video playback, the player will just quit. This is added only because some users seem to want it. I don't intend to make mpv a good DVD player, so the very basic minimum will have to do. How about you just convert your DVD to proper video files?
* options: add option to disable using right Alt key as Alt GrVivek Jain2013-12-021-0/+4
| | | | | | | | | mpv was hardcoded to always consider the right Alt key as Alt Gr, but there are parituclar combinations of platforms and keyboard layouts where it's more convenient to treat the right Alt as a keyboard modifier just like the left one. Fixes #388
* command: add a revert_seek commandwm42013-12-011-0/+1
| | | | As discussed on IRC.
* command: add a cycle_values input commandwm42013-11-301-0/+1
|
* input: use separate type for command definitionswm42013-11-281-3/+2
| | | | | | | | | | | | | Introduce a mp_cmd_def struct to define commands, instead of using mp_cmd for this. This way each command parameter can be a m_option, instead of m_option plus some more stuff. Define the ARG_ macros directly in terms of the OPT_ macros. Not sure if this makes it easier to read (maybe not, even if it looks simpler), but at least it makes it easier to add other option types. Another idea was adding a name for each parameter (so you could have named parameters), but not today.
* input: remove unused key_down_event commandwm42013-11-061-1/+0
| | | | | There's no real use-case for this, and is wasn't documented (didn't even appear on the "undocumented commands" list).
* input: disallow autorepeat by default for most commandswm42013-11-061-1/+2
| | | | | | | | | | This drops autorepeated key events for a number of commands. This should help with slow situations accidentally triggering too many repeats. (I'm not sure if this actually happened to users - maybe.) It's not clear whether MP_CMD_COMMAND_LIST (multiple commands on one binding separated by ';') should be repeated, or whether it should try to do something clever. For now, disallow autorepeat with it.
* command: replace speed_mult with multiply commandwm42013-10-311-1/+0
| | | | The compatibility layer still takes care of the old speed_mult command.
* command: add generic "multiply" commandwm42013-10-311-0/+1
| | | | Essentially works like "add".
* command: disable autorepeat for some commands (actually properties)wm42013-10-281-0/+1
| | | | | | | | | | | | Disable autorepeat for the "add"/"cycle" commands when changing properties that are choices (such as fullscreen, pause, and more). In these cases, autorepeat is not very useful, and can rather harmful effects (like triggering too many repeated commands if command execution is slow). (Actually, the commands are just dropped _after_ being repeated, since input.c itself does not know enough about the commands to decide whether or not they should be repeated.)
* command: add commands for displaying overlayswm42013-10-051-0/+3
| | | | | | Requested by github issue #255. Does not work where mmap is not available (i.e. Windows).
* command: add sub_seek input commandwm42013-10-021-0/+1
| | | | | | | Essentially reuses the sub_step command, and is subject to the same restrictions. Seems to behave a bit strange sometimes, but generally works.
* input: remove strange offset from commands enumwm42013-10-021-1/+1
| | | | A leftover from 10 years of refactoring.
* input: more mp_msg conversionwm42013-09-271-1/+2
| | | | | | | | It appears the last run missed all mp_tmsg(). Since the command parser also prints messages, it needs a new parameter to pass a log context. We go the easy way and just require the input_ctx to be passed, and use its mp_log.
* Add initial Lua scripting supportwm42013-09-261-0/+3
| | | | | | | | | | | | | | | | | | | | | | This is preliminary. There are still tons of issues, and any aspect of scripting may change in the future. I decided to merge this (preliminary) work now because it makes it easier to develop it, not because it's done. lua.rst is clear enough about it (plus some sarcasm). This requires linking to Lua. Lua has no official pkg-config file, but there are distribution specific .pc files, all with different names. Adding a non-pkg-config based configure test was considered, but we'd rather not. One major complication is that libquvi links against Lua too, and if the Lua version is different from mpv's, you will get a crash as soon as libquvi uses Lua. (libquvi by design always runs when a file is opened.) I would consider this the problem of distros and whoever builds mpv, but to make things easier for users, we add a terrible runtime test to the configure script, which probes whether libquvi will crash. This is disabled when cross-compiling, but in that case we hope the user knows what he is doing.
* input: convert to new msg APIStefano Pigozzi2013-09-101-2/+2
|
* input: don't deliver mouse events if mouse area is not setwm42013-09-081-0/+2
| | | | | | | | | | | | | | | | | | | | | This caused the OSC to be always visible at startup on X11: - EnterNotify event send a mouse event to input.c - OSC has not completely initialized yet, and no mouse area is set - mouse event is dispatched to "showhide" OSC section - OSC becomes visible, regardless of mouse position Fix this by treating the mouse area as empty if it's not set, instead of infinite as it was before this commit. This means an input section must set a mouse area to receive mouse events at all. We also have to change the default section to receive mouse events with the new behavior. Also, if MOUSE_MOVE is unmapped (or mapped to something that doesn't parse), and produces no command, the mouse position wouldn't be updated (because the mouse position is bound to input commands), so we have to generate a dummy command in this case. (This matters only for the OSC, On Screen Controller, which isn't merged yet, so these changes shouldn't have much effect right now.)
* input: allow window dragging even if mouse is in a mouse areawm42013-09-011-0/+2
| | | | | | If the input section is enabled with MP_INPUT_ALLOW_VO_DRAGGING, then the VO will be allowed to drag the window with mouse button down + mouse move even if the mouse is inside the section's mouse area.
* input: add support for precise scroll axesAlexander Preisinger2013-08-071-0/+5
| | | | | | | | | | | | | | | Support horizontal and vertical axes of input devices. If the input device support precise scrolling with an input value then it should first be scaled to a standard multiplier, where 1.0 is the default. The multiplier will then applied to the following commands if possible: * MP_CMD_SEEK * MP_CMD_SPEED_MULT * MP_CMD_ADD All other commands will triggered on every axis event, without change the values specified in the config file.
* core: move contents to mpvcore (2/2)Stefano Pigozzi2013-08-061-2/+2
| | | | Followup commit. Fixes all the files references.
* core: move contents to mpvcore (1/2)Stefano Pigozzi2013-08-061-0/+273
core is used in many unix systems for core dumps. For that reason some tools work under the assumption that the file is indeed a core dump (for example autoconf does this). This commit just renames the files. The following one will change all the includes to fix compilation. This is done this way because git has a easier time tracing file changes if there is a pure rename commit.
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-18 10:42:47 +0000