summaryrefslogtreecommitdiffstats
path: root/input/input.h
Commit message (Collapse)AuthorAgeFilesLines
* input: remove some unneeded thingswm42015-05-261-13/+0
| | | | | Wakeup FDs are not needed anymore (this code exists only for libwaio usage by now), and 2 other functions can be made private.
* Update license headersMarcin Kurczewski2015-04-131-5/+4
| | | | Signed-off-by: wm4 <wm4@nowhere>
* input: remove Linux joystick supportwm42015-03-241-1/+0
| | | | | | | | | | | Why did this exist in the first place? Other than being completely useless, this even caused some regressions in the past. For example, there was the case of a laptop exposing its accelerometer as joystick device, which led to extremely fun things due to the default mappings of axis movement being mapped to seeking. I suppose those who really want to use their joystick to control a media player (???) can configure it as mouse device or so.
* input: remove classic LIRC supportwm42015-03-241-1/+0
| | | | It's much easier to configure remotes as X11 input devices.
* input: simplifywm42014-11-241-1/+1
|
* input, lua: redo input handlingwm42014-11-231-3/+6
| | | | | Much of it is the same, but now there's the possibility to distinguish key down/up events in the Lua API.
* input: add a prefix to make any binding act on key repeatwm42014-11-201-0/+1
| | | | | | The fact that it's a generic command prefix that is parsed even when using the client API is a bit unclean (because this flag makes sense for actual key-bindings only), but it's less code this way.
* ipc: decouple from MPContextwm42014-10-191-1/+7
| | | | Just a minor refactor to keep unneeded dependencies on the core low.
* command: add a mechanism to allow scripts to intercept file loadswm42014-10-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | A vague idea to get something similar what libquvi did. Undocumented because it might change a lot, or even be removed. To give an idea what it does, a Lua script could do the following: -- type ID priority mp.commandv("hook_add", "on_load", 0, 0) mp.register_script_message("hook_run", function(param, param2) -- param is "0", the user-chosen ID from the hook_add command -- param2 is the magic value that has to be passed to finish -- the hook mp.resume_all() -- do something, maybe set options that are reset on end: mp.set_property("file-local-options/name", "value") -- or change the URL that's being opened: local url = mp.get_property("stream-open-filename") mp.set_property("stream-open-filename", url .. ".png") -- let the player (or the next script) continue mp.commandv("hook_ack", param2) end)
* input: use mpv_node parser for char** command parserswm42014-10-101-2/+1
| | | | Minor simplification, also drops some useless stuff.
* client API: rename --input-x11-keyboard to --input-vo-keyboardwm42014-10-091-1/+1
| | | | | Apparently we need this for Cocoa too. (The option was X11 specific in the hope that only X11 would need this hack.)
* client API, X11: change default keyboard input handling againwm42014-09-281-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Commit 64b7811c tried to do the "right thing" with respect to whether keyboard input should be enabled or not. It turns out that X11 does something stupid by design. All modern toolkits work around this native X11 behavior, but embedding breaks these workarounds. The only way to handle this correctly is the XEmbed protocol. It needs to be supported by the toolkit, and probably also some mpv support. But Qt has inconsistent support for it. In Qt 4, a X11 specific embedding widget was needed. Qt 5.0 doesn't support it at all. Qt 5.1 apparently supports it via QWindow, but if it really does, I couldn't get it to work. So add a hack instead. The new --input-x11-keyboard option controls whether mpv should enable keyboard input on the X11 window or not. In the command line player, it's enabled by default, but in libmpv it's disabled. This hack has the same problem as all previous embedding had: move the mouse outside of the window, and you don't get keyboard input anymore. Likewise, mpv will steal all keyboard input from the parent application as long as the mouse is inside of the mpv window. Also see issue #1090.
* input: separate creation and loading of configwm42014-09-271-0/+3
| | | | | | | | | | | Until now, creating the input_ctx was delayed until the command line and config files were parsed. Separate creation and loading so that input_ctx is available from start. This should make it possible to simplify some things. For example, some complications with Cocoa were apparently only because input_ctx was available only "later". (Although I'm not sure if this is still relevant, or if the Cocoa code should even be organized this way.)
* input: add function for setting repeat infoAlexander Preisinger2014-09-191-0/+2
| | | | | | | Let us set a different rate and delay. Needed for the following commit where we set rate and delay reported by weston. But only if the option native-keyrepeat is set.
* input: use libwaio for pipe input on Windowswm42014-09-141-10/+14
| | | | | | | | | | | | Use libwaio to read from pipes (stdin or named pipes) on Windows. This liberates us from nasty issues, such as pipes (as created by most programs) not being possible to read in a non-blocking or event-driven way. Although it would be possible to do that in a somewhat sane way on Vista+, it's still not easy, and on XP it's especially hard. libwaio handles these things for us. Move pipe.c to pipe-unix.c, and remove Windows specific things. Also adjust the input.c code to make this work cleanly.
* stream: redo playback abort handlingwm42014-09-131-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This mechanism originates from MPlayer's way of dealing with blocking network, but it's still useful. On opening and closing, mpv waits for network synchronously, and also some obscure commands and use-cases can lead to such blocking. In these situations, the stream is asynchronously forced to stop by "interrupting" it. The old design interrupting I/O was a bit broken: polling with a callback, instead of actively interrupting it. Change the direction of this. There is no callback anymore, and the player calls mp_cancel_trigger() to force the stream to return. libavformat (via stream_lavf.c) has the old broken design, and fixing it would require fixing libavformat, which won't happen so quickly. So we have to keep that part. But everything above the stream layer is prepared for a better design, and more sophisticated methods than mp_cancel_test() could be easily introduced. There's still one problem: commands are still run in the central playback loop, which we assume can block on I/O in the worst case. That's not a problem yet, because we simply mark some commands as being able to stop playback of the current file ("quit" etc.), so input.c could abort playback as soon as such a command is queued. But there are also commands abort playback only conditionally, and the logic for that is in the playback core and thus "unreachable". For example, "playlist_next" aborts playback only if there's a next file. We don't want it to always abort playback. As a quite ugly hack, abort playback only if at least 2 abort commands are queued - this pretty much happens only if the core is frozen and doesn't react to input.
* input: remove central select() callwm42014-09-101-39/+2
| | | | | This is now unused. Get rid of it and all surrounding infrastructure, and replace the remaining "wakeup pipe" with a semaphore.
* input: remove useless joystick.h/lirc.h include fileswm42014-09-101-0/+2
| | | | These really just waste space.
* input: add convenience function for running input sources in threadswm42014-09-101-0/+20
|
* input: make some fields internalwm42014-09-101-3/+1
|
* terminal-unix: move to threadwm42014-09-101-2/+0
| | | | | | | Do terminal input with a thread, instead of using the central select() loop. This also changes some details how SIGTERM is handled. Part of my crusade against mp_input_add_fd().
* player: some more input refactoringwm42014-09-071-6/+6
| | | | | | | | | | | | | | | | | Continues commit 348dfd93. Replace other places where input was manually fetched with common code. demux_was_interrupted() was a weird function; I'm not entirely sure about its original purpose, but now we can just replace it with simpler code as well. One difference is that we always look at the command queue, rather than just when cache initialization failed. Also, instead of discarding all but quit/playlist commands (aka abort command), run all commands. This could possibly lead to unwanted side-effects, like just ignoring commands that have no effect (consider pressing 'f' for fullscreen right on start: since the window is not created yet, it would get discarded). But playlist navigation still works as intended, and some if not all these problems already existed before that in some forms, so it should be ok.
* Move compat/ and bstr/ directory contents somewhere elsewm42014-08-291-1/+1
| | | | | | | | | bstr.c doesn't really deserve its own directory, and compat had just a few files, most of which may as well be in osdep. There isn't really any justification for these extra directories, so get rid of them. The compat/libav.h was empty - just delete it. We changed our approach to API compatibility, and will likely not need it anymore.
* input: redo how --input-file is handledwm42014-08-251-1/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | Abandon the "old" infrastructure for --input-file (mp_input_add_fd(), select() loop, non-blocking reads). Replace it with something that starts a reader thread, using blocking input. This is for the sake of Windows. Windows is a truly insane operating system, and there's not even a way to read a pipe in a non-blocking way, or to wait for new input in an interruptible way (like with poll()). And unfortunately, some want to use pipe to send input to mpv. There are probably (slightly) better IPC mechanisms available on Windows, but for the sake of platform uniformity, make this work again for now. On Vista+, CancelIoEx() could probably be used. But there's no way on XP. Also, that function doesn't work on wine, making development harder. We could forcibly terminate the thread, which might work, but is unsafe. So what we do is starting a thread, and if we don't want the pipe input anymore, we just abandon the thread. The thread might remain blocked forever, but if we exit the process, the kernel will forcibly kill it. On Unix, just use poll() to handle this. Unfortunately the code is pretty crappy, but it's ok, because it's late and I wanted to stop working on this an hour ago. Tested on wine; might not work on a real Windows.
* vo: remove vo_mouse_movement() wrapperwm42014-07-271-0/+3
| | | | So that VO backends don't have to access the VO just for that.
* vo: different hack for VOs which need to mangle mouse inputwm42014-07-271-0/+7
| | | | | | | | Follow up on commit 760548da. Mouse handling is a bit confusing, because there are at least 3 coordinate systems associated with it, and it should be cleaned up. But that is hard, so just apply a hack which gets the currently-annoying issue (VO backends needing access to the VO) out of the way.
* input: remove pausing command prefixeswm42014-05-111-3/+0
| | | | | | These are now equivalent to combining commands with the "cycle pause" or "set pause" commands, and thus are not needed anymore. They were also obscure and undocumented.
* stream: make mp_input_check_interrupt thread-safewm42014-04-251-0/+2
| | | | | | | | | | | | | | | | The interrupt callback will can be called from another thread if the cache is enabled, and the stream disconnects. Then stream_reconnect() will call this function from within the cache thread. mp_input_check_interrupt() is not thread-safe due to read_events() not being thread-safe. It will call input callbacks added with mp_input_add_fd() - these callbacks lead to code not protected by locks, such as reading X11 events. Solve this by adding a stupid hack, which checks whether the calling thread is the main playback thread (i.e. calling the input callbacks will be safe). We can remove this hack later, but it requires at least moving the VO to its own thread first.
* stream: remove interrupt callback global variableswm42014-04-251-1/+1
| | | | | | | | | | | | This used global variables for the asynchronous interrupt callback. Pick the simple and dumb solution and stuff the callback into mpv_global. Do this because interrupt checking should also work in the connect phase, and currently stream creation equates connecting. Ideally, this would be passed to the stream on creation instead, or connecting would be separated from creation. But since I don't know yet which is better, and since moving stream/demuxer into their own thread is something that will happen later, go with the mpv_global solution.
* audio: wake up the core when audio buffer is running low (2)wm42014-04-151-0/+2
| | | | | | | | | | | | | | Same change as in e2184fcb, but this time for pull based AOs. This is slightly controversial, because it will make a fast syscall from e.g. ao_jack. And according to JackAudio developers, syscalls are evil and will destroy realtime operation. But I don't think this is an issue at all. Still avoid locking a mutex. I'm not sure what jackaudio does in the worst case - but if they set the jackaudio thread (and only this thread) to realtime, we might run into deadlock situations due to priority inversion and such. I'm not quite sure whether this can happen, but I'll readily follow the cargo cult if it makes hack happy.
* command: provide per-file-options for loadfile commandxylosper2014-02-231-0/+1
| | | | | | Signed-off-by: wm4 <wm4@nowhere> Closes #575. Minor changes over original pull request.
* input, dvdnav: fix osc stealing input from dvdnavwm42014-02-191-2/+4
| | | | | | | | | | This is a regression introduced from moving Lua scripts (including the OSC) to their own threads. Now OSC and dvdnav can add their bindings at the same time without coordination, which seems to result in the OSC winning most time, and thus overriding the dvdnav menu bindings. Fix this by adding a flag that makes dvdnav menu bindings take priority over all other bindings.
* input: change mp_input_run_cmd signaturewm42014-01-041-2/+2
| | | | | | | | I don't like this function at all, but it's basically a trick to get the input's mp_log instance in a case the mp_input_parse_cmd_strv() is almost certainly not going to output anything. But still make it somewhat more consistent with mp_input_parse_cmd_strv() - why force the caller to always use MP_ON_OSD_AUTO?
* input: move files drag and drop to a new event.c fileStefano Pigozzi2014-01-041-0/+4
| | | | | event.c will be used to feed the input queue with 'global' events that don't mesh well with the usual check_events path in mpv.
* input: split off some code from input.c to separate fileswm42013-12-261-100/+2
| | | | This is mostly just moving code around.
* input: rework how input sources are addedwm42013-12-211-12/+13
| | | | | | | | | | | | | | Until now, there were two functions to add input sources (stuff like stdin input, slave mode, lirc, joystick). Unify them to a single function (mp_input_add_fd()), and make sure the associated callbacks always have a context parameter. Change the lirc and joystick code such that they take store their state in a context struct (probably worthless), and use the new mp_msg replacements (the point of this refactoring). Additionally, get rid of the ugly USE_FD0_CMD_SELECT etc. ifdeffery in the terminal handling code.
* input: make parse_cmd_strv take const argsMartin Herkt2013-12-201-1/+1
|
* input, lua: add functions to take pre-split input commandswm42013-12-201-0/+13
| | | | | | | | | | | | | | So you can pass a command as list of strings (each item is an argument), instead of having to worry about escaping and such. These functions also take an argument for the default command flags. In particular, this allows setting saner defaults for commands sent by program code. Expose this to Lua as mp.send_commandv command (suggestions for a better name welcome). The Lua version doesn't allow setting the default command flags, but it can still use command prefixes. The default flags are different from input.conf, and disable OSD and property expansion.
* command: remove radio commandswm42013-12-191-4/+0
| | | | | | | Remove these because I'm too lazy to convert them to proper STREAM_CTRLs. Considering that probably nobody uses radio://, caring about this is a complete waste of time. I will add these commands back if someone asks for them, but I don't expect this to happen.
* Split mpvcore/ into common/, misc/, bstr/wm42013-12-171-1/+1
|
* Move options/config related files from mpvcore/ to options/wm42013-12-171-1/+1
| | | | | | | | | Since m_option.h and options.h are extremely often included, a lot of files have to be changed. Moving path.c/h to options/ is a bit questionable, but since this is mainly about access to config files (which are also handled in options/), it's probably ok.
* Move mpvcore/input/ to input/wm42013-12-171-0/+303
|
* Rename directories, move files (step 1 of 2) (does not compile)wm42012-11-121-219/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tis drops the silly lib prefixes, and attempts to organize the tree in a more logical way. Make the top-level directory less cluttered as well. Renames the following directories: libaf -> audio/filter libao2 -> audio/out libvo -> video/out libmpdemux -> demux Split libmpcodecs: vf* -> video/filter vd*, dec_video.* -> video/decode mp_image*, img_format*, ... -> video/ ad*, dec_audio.* -> audio/decode libaf/format.* is moved to audio/ - this is similar to how mp_image.* is located in video/. Move most top-level .c/.h files to core. (talloc.c/.h is left on top- level, because it's external.) Park some of the more annoying files in compat/. Some of these are relicts from the time mplayer used ffmpeg internals. sub/ is not split, because it's too much of a mess (subtitle code is mixed with OSD display and rendering). Maybe the organization of core is not ideal: it mixes playback core (like mplayer.c) and utility helpers (like bstr.c/h). Should the need arise, the playback core will be moved somewhere else, while core contains all helper and common code.
* input: add input test modewm42012-10-141-0/+1
| | | | | | | | | | | In input test mode, key bindings won't be executed, but are shown on the OSD. The OSD includes various information, such as the name of the key, the command itself, whether it's builtin, and the config file location it was defined. The input test mode can be enabled with "--input=test". No effort is spent trying to react to key bindings that normally exit the player; they are treated just like any other binding.
* input: track location info for input commandswm42012-10-141-2/+3
| | | | | | If parsing a command fails, its location is printed. The location is the path to the input.conf, and the line number of the key binding and the associated input command.
* commands: add print_text input command to print text on the terminalwm42012-10-121-0/+1
| | | | | In theory, this could take over the role of the get_property slave command, and is more general.
* commands: more user-control whether a command shows OSD bars/messageswm42012-10-121-2/+4
| | | | | | | | | | The "no-osd" prefix was introduced earlier to disable OSD selectively based on the key binding. Extend this, and allow the user to force display of an OSD bar ("osd-bar"), OSD message ("osd-msg") or both ("osd-msg-bar"). This changes mainly how property setting functions behave. The default behavior is still the same.
* commands: add choice type to input commandswm42012-10-121-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Allow using the choice type (as it used for command line) for arguments of input commands. Change the magic integer arguments of some commands (like seek) to use choices instead. The old numeric values are still allowed (but only those which made sense before, not arbitrary integers). In order to do this, remove the input.c specific types (like MP_CMD_ARG_INT) completely and specify commands using the m_option types. Also, add the special choice "-" to some arguments. It's supposed to signify the default value, so arguments can be easily skipped. Maybe the choice option should recognize this and not change the previous value, but we'll leave this for later. For now, leave compatibility integer values for all new choice arguments, e.g. "0" maps to 0. We could let the choice option type do this automatically, but we don't, because we want user input values and internal mplayer values decoupled in general. The compatibility options will be removed one day, too. Also, remove optional args for strings - would require either annoying additional code, or copying strings twice. It's not used, so remove it.
* input: warn about non-existing commands, add explicit "ignore" commandwm42012-10-121-0/+1
| | | | | | | | | | | If a command is not found, warn about it at loading time (just like other command parsing errors are printed at loading time). Add an explicit "ignore" command. input.conf instructs users to use this command to cancel out existing mapping. This clashed with the warning added in this commit. Make "ignore" a real command and remove the specialcasing for it from get_cmd_from_keys(). Now "ignore" is ignored because it's not handled in command.c.
* input: verify input.conf on loadingwm42012-10-121-1/+2
| | | | | | | | | When input.conf is loaded, verify each command and print a warning if it's invalid or uses legacy commands. This is done for both the user's and the embedded config files. The diff is a bit noisy, because mp_input_parse_cmd() is changed to take a bstr as argument instead of a char*.
* commands: replace "switch" with "add" and "cycle"wm42012-10-121-1/+2
| | | | | | | | | | | | | | Now it depends on the command whether a property wraps around, or stops at min/max valid property value. For practically all properties, it's quite unambiguous what the "switch" command should have done, and there's technically no need to replace it with these new commands. More over, most properties that cycle are boolean anyway. But it seems more orthogonal to make the difference explicit, rather than hardcoding it. Having different commands also makes it more explicit to the user what these commands do, both just due to the naming, and what wrapping policy is used. The code is simpler too.
* commands: make "aspect" property writeable, replaces "switch_ratio"wm42012-10-121-1/+0
| | | | | | | | Move the code for "switch_ratio" to the M_PROPERTY_SET case of the "aspect" property. The rules are exactly the same, e.g. setting a ratio smaller than 0.1 sets the pixel aspect ratio to 1:1. For now, we define that writing "0" sets the PAR to 1:1, and disallow -1 (possibly reserve it to reset to default aspect ratio).
* commands: rename osd_show_[property_]text and osd_show_progressionwm42012-10-121