summaryrefslogtreecommitdiffstats
path: root/input
Commit message (Collapse)AuthorAgeFilesLines
* 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 document "stop". It seems somewhat useful for client API users (although that will be implemented properly only in the following commits.)
* input: don't autorepeat cycle_values commandwm42014-09-131-1/+1
| | | | | | | Not sure why this was originally added as autorepeated. It makes no sense, because switching between choices should never autorepeat. (For the normal "add"/"cycle" commands, autorepeat is usually enabled, but command.c tries to disable it specifically for choice properties.)
* input: simplifywm42014-09-131-45/+29
| | | | | Just some minor things. In particular, don't call mp_input_wakeup() manually, but make it part of queuing commands (as far as possible).
* input: fix autorepeatwm42014-09-131-2/+3
| | | | | | | | Mismatching units in timeout calculation. Also, as a near-cosmetic change, explicitly wake up the core on the right time. Currently this does nothing, because the core is woken up anyway - but it will matter with the next commit.
* input: remove central select() callwm42014-09-103-412/+37
| | | | | 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-106-67/+6
| | | | These really just waste space.
* input: use an input thread for joystickwm42014-09-103-17/+51
|
* input: use an input thread for lircwm42014-09-103-17/+47
|
* input: add convenience function for running input sources in threadswm42014-09-102-1/+91
|
* input: make some fields internalwm42014-09-102-13/+19
|
* terminal-unix: move to threadwm42014-09-102-21/+1
| | | | | | | 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().
* input: fix missed wakeups, simplifywm42014-09-091-26/+10
| | | | | mp_input_read_cmd() reset the wakeup flag, but only mp_input_wait() should be able to do that.
* input: fix use after free with legacy commandswm42014-09-081-7/+11
| | | | | | | | To handle legacy commands, string replacement is used; the modified string is returned by parse_cmd_str(), but it also frees all temporary memory, which includes the replaced string. Closes #1075.
* input: fix exiting with signalswm42014-09-081-2/+2
| | | | | Quitting through SIGTERM etc. was accidentally ignored since commit f5af5962 from today.
* player: some more input refactoringwm42014-09-072-17/+24
| | | | | | | | | | | | | | | | | 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.
* input: make ar_rate and ar_delay fields of input_ctx signedshdown2014-08-301-2/+2
| | | | | ar_rate is set to -1 when autorepeat is disabled; there is no reason for ar_delay to stay unsigned.
* input: handle reaching MP_MAX_FDS correctlyshdown2014-08-301-10/+10
| | | | Don't dereference fd and increment ictx->num_fds on fail.
* Move compat/ and bstr/ directory contents somewhere elsewm42014-08-296-6/+6
| | | | | | | | | 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.
* posix: use STD*_FILENO constantsBen Boeckel2014-08-281-1/+1
| | | | | Rather than "magic" numbers, use meaningful constant names provided by unistd.h.
* input: make key bindings like "Shift+X" work (for ASCII)wm42014-08-263-13/+30
| | | | | | | | | | | | | | "Shift+X" didn't actually map any key, as opposed to "Shift+x". This is because shift usually changes the case of a character, so a plain printable character like "X" simply can never be combined with shift. But this is not very intuitive. Always remove the shift code from printable characters. Also, for ASCII, actually apply the case mapping to uppercase characters if combined with shift. Doing this for unicode in general would be nice, but that would require lookup tables. In general, we don't know anyway what character a key produces when combined with shift - it could be anything, and depends on the keyboard layout.
* input: make all modifier flags unsignedwm42014-08-261-8/+8
|
* input: stdin is 0, not 1wm42014-08-251-1/+1
| | | | Oops. I can never remember this right.
* input: redo how --input-file is handledwm42014-08-253-24/+261
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* input: change verbosity of some message levelswm42014-08-251-3/+4
| | | | | | | For --input-test, print messages on terminal by default. Raise message level for enabling input sections, because the OSC makes this very extremely annoying.
* input: fix event wakeupwm42014-08-111-18/+14
| | | | | | | | When a new event was added, merely a flag was set, instead of actually waking up the core (if needed). This was ok in ancient times when all event sources were part of the select() loop. But now there are several cases where other threads can add input, and then you actually need to wakeup the core in order to make it read the events at all.
* input: fix off by one error in command parserwm42014-08-071-1/+1
| | | | Should fix #989.
* input: be stricter about rejecting mouse input with --no-input-cursorwm42014-07-272-0/+5
| | | | | | | Apparently this switch means all mouse input should be strictly rejected. Some VO backends (such as X11) explicitly disable all mouse events if this option is set, but others don't. So check them in input.c, which increases consistency.
* vo: remove vo_mouse_movement() wrapperwm42014-07-272-0/+21
| | | | 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-272-0/+36
| | | | | | | | 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.
* osdep: don't assume errno is positivewm42014-07-251-1/+1
| | | | | Apparently this is not necessarily the case, so just drop the silly idea that depended on this assumption.
* command: add append-play loadfile modewm42014-07-231-1/+2
| | | | | | | | "loadfile filename append-play" will now always append the file to the playlist, and if nothing is playing yet, start playback. I don't want to change the semantics of "append" mode, so a new mode is needed. Probably fixes issue #950.
* input: enable wakeup on LIRC socketfoo862014-07-201-1/+1
| | | | | Commit dc00b14 removed playloop polling. Enable wakeup on LIRC socket, otherwise remote control doesn't work when paused.
* input: skip BOM in input.confwm42014-07-121-0/+1
|
* build: include <strings.h> for strcasecmp()wm42014-07-101-0/+1
| | | | | | | It happens to work without strings.h on glibc or with _GNU_SOURCE, but the POSIX standard requires including <strings.h>. Hopefully fixes OSX build.
* input: restore ability to combine mouse buttonswm42014-07-071-8/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | Key bindings are decided on the "down" event, so if the prefix is not unique, the first/shortest will be used (e.g. when both "a" and "a-b" are mapped, "a" will always be chosen). This also breaks combining multiple mouse buttons. But it seems users expect it to work, and it's indeed a bit strange that it shouldn't work, as mouse bindings are emitted on the key "up" event, not "down" (if the shorter binding didn't emit a command yet, why shouldn't it be combinable). Deal with this by clearing the key history when a command is actually emitted, instead of when a command is decided. This means if both MOUSE_BTN0 and MOUSE_BTN0-MOUSE_BTN1 are mapped, the sequence of holding down BTN0 and then BTN1 will redecide the current command. On the other hand, if BTN0 is released before BTN1 is pressed, the command is emitted, and the key history is deleted. So the BTN1 press will not trigger BTN0-BTN1. For normal keys, nothing should change, because commands are emitted on the "down" event already, so the key history is always cleared. Might fix #902. CC: @mpv-player/stable (if this fix is successful)
* Audit and replace all ctype.h useswm42014-07-011-1/+0
| | | | | | | | | | | | | | | | Something like "char *s = ...; isdigit(s[0]);" triggers undefined behavior, because char can be signed, and thus s[0] can be a negative value. The is*() functions require unsigned char _or_ EOF. EOF is a special value outside of unsigned char range, thus the argument to the is*() functions can't be a char. This undefined behavior can actually trigger crashes if the implementation of these functions e.g. uses lookup tables, which are then indexed with out-of-range values. Replace all <ctype.h> uses with our own custom mp_is*() functions added with misc/ctype.h. As a bonus, these functions are locale-independent. (Although currently, we _require_ C locale for other reasons.)
* input: make option struct localwm42014-06-111-27/+56
| | | | | | | | | Similar to previous commits. This also renames --doubleclick-time to --input-doubleclick-time, and --key-fifo-size to --input-key-fifo-size. We could keep the old names, but these options are very obscure, and renaming them seems better for consistency.
* command: redo ancient TV/DVB/PVR commandswm42014-06-112-21/+0
| | | | | | | | | | | | | | | | | | Convert all these commands to properties. (Except tv_last_channel, not sure what to do with this.) Also, internally, don't access stream details directly, but dispatch commands with stream ctrls. Many of the new properties are a bit strange, because they're write- only. Also remove some OSD output these commands produced, because I couldn't be bothered to port these. In general, this makes everything much cleaner, and will also make it easier to e.g. move the demuxer to its own thread. Don't bother updating input.conf, but changes.rst documents how old commands map to the new ones. Mostly untested, due to lack of hardware.
* input: don't print warning when aboting playback via commandswm42014-06-061-6/+1
| | | | I don't really see a reason for this.
* input: separate wakeup pipe creation into a separate functionwm42014-05-301-13/+2
| | | | | Error handling is slightly reduced: we assume that setting a pipe to non-blocking can never fail.
* input: make combined commands repeatablewm42014-05-263-2/+10
| | | | | | | | Binding multiple commands at once where always considered not repeatable, because the MP_CMD_COMMAND_LIST wasn't considered repeatable. Fixes #807 (probably).
* command: add write_watch_later_config commandMartin2014-05-262-0/+4
| | | | | | Closes #808. Signed-off-by: wm4 <wm4@nowhere>
* player: give quit_watch_later an exit code argument like quitwm42014-05-221-1/+1
| | | | | | | | The quit command has an optional argument that is used as exit code. Extend that to the quit_watch_later command. Actually, unify the implementations of the two commands. Requested in #798.
* input: allow disabling window dragging with --no-window-draggingwm42014-05-201-1/+7
| | | | Requested in github issue #608.
* input: fix compilation on windowswm42014-05-201-4/+2
| | | | | Currently I don't have a crosscompilation toolchain, so I couldn't test whether this actually compiles (and still can't).
* input: remove pausing command prefixeswm42014-05-112-5/+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.
* input: fix typos, cosmeticswm42014-05-101-10/+10
|
* options: rename input-related optionsMartin Herkt2014-05-041-7/+7
| | | | | | | |