summaryrefslogtreecommitdiffstats
path: root/input
Commit message (Collapse)AuthorAgeFilesLines
* x11: add XK_Cancel to the list of special keysMartin Herkt2015-02-142-0/+2
| | | | | Some IR receivers emit this key by default for remote control buttons. Make it mappable.
* x11: make all XF86 special keys mappablewm42015-02-131-1/+6
| | | | | | | | Makes all keys documented in XF86keysym.h mappable. This requires the user to deal with numeric keycodes; no names are queried or exported. This is an easy way to avoid adding all the hundreds of XF86 keys to our X11 lookup table and mpv's keycode/name list.
* ipc: put playback core to sleep while dequeuing commandswm42015-02-131-1/+7
| | | | | | | Happens to fix #1581 due to an unfortunate interaction with the way the VO does not react to commands for a while if a video frame is queued. Slightly improves other situations as well, if the client spams mpv with commands during playback.
* command: new commands audio_add/audio_remove/audio_reloadxylosper2015-02-032-0/+9
| | | | | | | | These commands are counterparts of sub_add/sub_remove/sub_reload which work for external audio file. Signed-off-by: wm4 <wm4@nowhere> (minor simplification)
* input: fix dangling pointerwm42015-01-251-0/+1
| | | | Removes undefined behavior that showed up as crap when running with -v.
* input, player: new command for mouse eventxylosper2015-01-232-0/+9
| | | | | | | New command `mouse <x> <y> [<button> [single|double]]` is introduced. This will update mouse position with given coordinate (`<x>`, `<y>`), and additionally, send single-click or double-click event if `<button>` is given.
* input: handle mixing key press and up/down events betterwm42015-01-231-4/+5
|
* client API: reasonable behavior if window is closedwm42015-01-121-0/+2
| | | | | | | | | | | | | | | | Closing the video window sends CLOSE_WIN, which is normally mapped to the "quit" command. The client API normally disables all key bindings, and closing the window does nothing. It's simply left to the application to handle this. This is fine - an embedded window can not be destroyed by user interaction. But sometimes, the window might be destroyed anyway, for example because the containing window is destroyed. If this happens, CLOSE_WIN should better not be ignored. We can't expect client API users to handle this specially (by providing their own input.conf), so provide some fallback for this pseudo key binding. The "quit" command might be too intrusive (not every client necessarily handles "unexpected" MPV_EVENT_SHUTDOWN), but I think it's still reasonable.
* ipc: add enable_event and disable_event commandswm42014-12-241-0/+33
| | | | This was requested.
* ipc: report some user errors betterwm42014-12-241-2/+5
| | | | | | | | | | | | | | | Using the IPC with a program, it's not often obvious that a newline must be sent to terminate a command. Print a warning if the connection is closed while there is still uninterpreted data in the buffer. Print the OS reported error if reading/writing the socket fails. Print an erro if JSON parsing fails. I considered silencing write errors if the write end is closed (EPIPE), because a client might send a bunch of commands, and then close the socket without wanting to read the reply. But then, mpv disconnects without reading further commands that might still be buffered, so it's probably a good idea to always print the error.
* command: extend revert_seek commandwm42014-12-171-1/+3
| | | | | "revert_seek mark" basically forces the seekback point. It's basically a one-way bookmark.
* client API: be more lenient about mpv_suspend/resume mismatcheswm42014-12-151-16/+4
| | | | | | | | | | | | Before this commit, this was defined to trigger undefined behavior. This was nice because it required less code; but on the other hand, Lua as well as IPC support had to check these things manually. Do it directly in the API to avoid code duplication, and to make the API more robust. (The total code size still grows, though...) Since all of the failure cases were originally meant to ruin things forever, there is no way to return error codes. So just print the errors.
* pipe-win32: possible fix for Windows XP deadlockJames Ross-Gowan2014-12-111-0/+10
| | | | | This fixes a hang with the VirtualBox OpenGL drivers. It might help with #1325 as well.
* input: add a hack to fix keyboard navigation with dvd/bd menuwm42014-12-041-0/+2
| | | | | | | | | | If the user has LEFT/RIGHT/etc. bound in his input.conf, then these were overriding the menu keys in dvdnav mode. This hack works because the dvdnav crap happens to be the only user of MP_INPUT_ON_TOP. If it finds a default key binding in the dvdnav menu section, it will use that, instead of continuing search and possibly finding the user key bindings meant for normal playback.
* input, lua: make removing key bindings workwm42014-12-031-3/+4
| | | | | | This just kept adding bindings to the input section, rather than defining it. One bad effect was that mp.remove_key_binding() in Lua didn't work.
* Do not call strerror()wm42014-11-262-6/+12
| | | | | | | | | | | | | | | | | | | | | | | | | ...because everything is terrible. strerror() is not documented as having to be thread-safe by POSIX and C11. (Which is pretty much bullshit, because both mandate threads and some form of thread-local storage - so there's no excuse why implementation couldn't implement this in a thread-safe way. Especially with C11 this is ridiculous, because there is no way to use threads and convert error numbers to strings at the same time!) Since we heavily use threads now, we should avoid unsafe functions like strerror(). strerror_r() is in POSIX, but GNU/glibc deliberately fucks it up and gives the function different semantics than the POSIX one. It's a bit of work to convince this piece of shit to expose the POSIX standard function, and not the messed up GNU one. strerror_l() is also in POSIX, but only since the 2008 standard, and thus is not widespread. The solution is using avlibc (libavutil, by its official name), which handles the unportable details for us, mostly. We avoid some pain.
* input: simplifywm42014-11-245-38/+25
|
* lua: always handle key repeat on the script sidewm42014-11-241-1/+3
| | | | | | Simpler, and leaves the decision to repeat or not fully to the script (instead of requiring the user to care about it when remapping a script binding).
* lua, ipc: remove leftoverswm42014-11-241-9/+0
| | | | | | MPV_EVENT_SCRIPT_INPUT_DISPATCH is now unused/deprecated. Also remove a debug-print from defaults.lua.
* command: don't queue framestepswm42014-11-231-0/+1
| | | | | If repeated framestep commands are sent, just unpause the player, instead of playing N frames for N repeated commands.
* input, lua: redo input handlingwm42014-11-234-10/+17
| | | | | Much of it is the same, but now there's the possibility to distinguish key down/up events in the Lua API.
* input: set mouse area by default for all inputwm42014-11-231-1/+2
| | | | | | | | | | Otherwise, mouse button bindings added by mp.add_key_binding() would be ignored. It's possible that this "breaks" some older scripts using undocumented Lua script functions, but it should be safe otherwise. Fixes #1283.
* Remove some unneeded NULL checkswm42014-11-211-1/+1
| | | | Found by Coverity; also see commit 85fb2af3.
* ipc: fix confusion of write() return value and errnowm42014-11-211-3/+3
| | | | Found by Coverity.
* input: add a prefix to make any binding act on key repeatwm42014-11-204-3/+7
| | | | | | 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.
* command: add drop_bufferswm42014-11-202-0/+4
| | | | | | | | | | | | | | | This command was actually requested on IRC ages ago, but I forgot about it. The main purpose is that the decoding state can be reset without issuing a seek, in particular in situations where you can't seek. This restarts decoding from the middle of the packet stream; since it discards the packet buffer intentionally, and the decoder will typically not output "incomplete" frames until it has recovered, it can skip a large amount of data. It doesn't clear the byte stream cache - I'm not sure if it should.
* command: add an ab_loop commandwm42014-11-182-0/+4
| | | | | | As suggested in #1241; to make using the feature easier. Also add better OSD-formatting for the ab-loop-a/b properties.
* ipc: make sure --input-file=/dev/stdin always workswm42014-11-071-7/+20
| | | | It's not necessarily available on Unix systems other than Linux (sigh).
* ipc: make it possible to receive log messageswm42014-11-011-0/+13
| | | | | The receiving part was implemented, but since no messages are enabled by default, it couldn't be used.
* ipc: add a command to retrieve API versionwm42014-11-011-0/+4
|
* ipc: verify resume/suspend commandswm42014-11-011-4/+16
| | | | | Calling mpv_resume() too often is considered an API usage violation, and will trigger an internal assertion somewhere.
* command: don't require whitespace before ';' or '#'wm42014-10-311-4/+1
| | | | | | | This change is probably too simplistic, but most things appear to work, so I don't care about that now. Fixes #1232.
* input: cascade-load input.confwm42014-10-291-8/+6
| | | | | If there are several input.confs in the set of valid config paths, load them all.
* audio: add command/function to reload audio outputwm42014-10-272-0/+2
| | | | | Anticipated use: simple solution for dealing with audio APIs which request configuration changes via events.
* input: resolve ~ and similar for --input-filewm42014-10-241-2/+3
| | | | Because why not.
* command: fix debug outputwm42014-10-241-2/+2
| | | | It was a bit ugly/annoying.
* command: print executed commands with -vwm42014-10-232-0/+23
|
* command: add a "cached" mode to sub_addwm42014-10-231-1/+1
| | | | | This avoids reloading a subtitle if it was already added. In all cases, the subtitle is selected.
* command: make trailing sub_add actually optionalwm42014-10-221-1/+2
| | | | This was always intended. Also fixes subtitle-file drag & drop.
* command: extend sub_add commandwm42014-10-211-1/+3
|
* Set thread name for debuggingwm42014-10-192-0/+7
| | | | | | | | | | Especially with other components (libavcodec, OSX stuff), the thread list can get quite populated. Setting the thread name helps when debugging. Since this is not portable, we check the OS variants in waf configure. old-configure just gets a special-case for glibc, since doing a full check here would probably be a waste of effort.
* ipc: skip empty and commented lineswm42014-10-191-2/+4
|
* ipc: accept both JSON and "old" commandswm42014-10-191-30/+27
| | | | Minimizes the differences between --input-file and --input-unix-socket.
* ipc: fix minor error cleanup issueswm42014-10-191-8/+8
| | | | | | | | | | | | | | The ipc_thread can exit any time, and will free the mp_ipc_ctx when doing this, leaving a dangling pointer. This was somewhat handled in the original commit by setting mpctx->ipc_ctx to NULL when the thread exited, but that was still a race condition. Handle it by freeing most things after joining the ipc_thread. This means some resources will not be freed until player exit, but that should be ok (it's an exceptional error situation). Also, actually close the pipe FDs in mp_init_ipc() on another error path.
* ipc: decouple from MPContextwm42014-10-192-42/+50
| | | | Just a minor refactor to keep unneeded dependencies on the core low.
* ipc: fix a small memory leakwm42014-10-171-1/+2
|
* input: implement --input-file on unix using the IPC supportAlessandro Ghedini2014-10-173-76/+60
|
* input: implement JSON-based IPC protocolAlessandro Ghedini2014-10-171-0/+723
|
* input: don't add weird padding when formatting keycodewm42014-10-171-1/+1
| | | | No idea what this was for. It has no purpose and looks weird.
* command: add a mechanism to allow scripts to intercept file loadswm42014-10-163-0/+7
| | | | | | | | | | | | | | | | | | | | | | | 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: remove some unneeded codewm42014-10-101-59/+25
|
* input: cosmetics: move codewm42014-10-101-68/+69
|
* input: use mpv_node parser for char** command parserswm42014-10-105-61/+41
| | | | Minor simplification, also drops some useless stuff.
* input: add a function to parse mpv_node as commandwm42014-10-102-62/+162
| | | | For future client API enhancements.
* libmpv/cocoa: don't start the event monitorStefano Pigozzi2014-10-091-0/+7
| | | | | | The event monitor is used to get keyboard events when there is no window, but since it is a global monitor to the current process, we don't want it in a library setting.
* client API: rename --input-x11-keyboard to --input-vo-keyboardwm42014-10-092-6/+7
| | | | | 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-282-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | 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: copy options automaticallywm42014-09-271-36/+29
| | | | | | Originally, all options were copied to ensure that input_ctx remins thread-safe, even if options are changed asynchronously. But this got a bit inconsistent. Copy them automatically and reduce some weirdness.
* input: separate creation and loading of configwm42014-09-272-14/+23
| | | | | | | | | | | 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: explain why we use semaphoreswm42014-09-201-3/+6
| | | | Also switch function names for better self-documentation.
* input: add locking for repeat infoAlexander Preisinger2014-09-191-0/+3
|
* input: add function for setting repeat infoAlexander Preisinger2014-09-192-0/+8
| | | | | | | 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-145-147/+175
| | | | | | | | | | | | 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.
* input: fix nested commandswm42014-09-131-1/+1
| | | | Regression from today.
* input: distinguish playlist navigation and quit commands for abortwm42014-09-133-28/+37
| | | | | | | Refine the ugly hack from the previous commit, and let the "quit" command and some others abort playback immediately. For playlist_next/playlist_prev, still use the old hack, because we can't know if they would stop playback or not.
* stream: redo playback abort handlingwm42014-09-132-9/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: "quit_watch_later" and "stop" are abort commandswm42014-09-131-0/+2
| | | | | | | | | This means they get special handling for asynchronously aborting playback, even if the player is "stuck". Also