fixes issue with | less, where mplayer broke less's terminal
expectations and made less quit
Note this means that read() will be blocking again. Should be ok, as we
always check via select() before reading.
This was intended for translating filenames from filesystem charset to
the terminal charset. Modern sane platforms use UTF-8 for everything,
and on Windows we use unicode APIs, so this is not needed anymore.
Remove filename_recode, all uses of it, options and configure checks
related to terminal output charset, and code that tries to determine
the same.
Stop trying to read terminal input if a read attempt returns EOF. The
most important case where this matters is when someone runs the player
with stdin redirected from /dev/null and without specifying
--no-consolecontrols. This used to cause 100% CPU load while paused,
as select() would continuously trigger on stdin (the need for
--no-consolecontrols was not apparent to people with older mplayer
versions, as input reading was less efficient and latencies like
hardcoded sleeps kept CPU use well below 100%). Now this will only
cause a "Dead key input" error message.
This assumes the terminal uses UTF-8. If invalid UTF-8 is encountered (for
example because the terminal uses a legacy encoding), the code falls back
to the old method and feeds each byte as key code to the input code.
In theory, UTF-8 input could randomly fail, because the code in getch2.c
doesn't try to fill the input buffer correctly with input sequences
longer than a byte. This is a problem with the design of the existing
code.
This moves all key codes above the highest valid unicode code point
(which is 0x10FFFF). All key codes below MP_KEY_BASE now directly map
to unicode (KEY_ENTER is 13, carriage return). Configuration files
(input.conf) can contain unicode characters in UTF-8 to map non-ASCII
characters/keys.
This shouldn't change anything user visible, except that "direct key
codes" (as used in input.conf) will change their meaning.
Parts of the bstr functions taken from libavutil's GET_UTF8 and
slightly modified.
Install a signal handler on SIGCONT, and restore the terminal
attributes with tcsetattr() if it happens. This is needed with some
shells (such as tcsh) that don't restore the terminal attributes set
by mplayer. Without this, terminal I/O doesn't work as intended after
resume with these shells.
Fixes#155.
The commit "input: handle UTF-8 terminal input" accidentally messed up
the handling of certain special keys. Apparently only KEY_ENTER was
affected by this, because the code was valid UTF-8, but didn't directly
map to the keycode.
This assumes the terminal uses UTF-8. If invalid UTF-8 is encountered (for
example because the terminal uses a legacy encoding), the code falls back
to the old method and feeds each byte as key code to the input code.
In theory, UTF-8 input could randomly fail, because the code in getch2.c
doesn't try to fill the input buffer correctly with input sequences
longer than a byte. This is a problem with the design of the existing
code.
This moves all key codes above the highest valid unicode code point (which
is 0x10FFFF). All key codes below MP_KEY_BASE now directly map to unicode.
Configuration files (input.conf) can contain unicode characters in UTF-8
to map non-ASCII characters/keys.
This shouldn't change anything user visible, except that "direct key codes"
(as used in input.conf) will change their meaning.
getch2.c read data into a "char" array, and returned values other than
escape sequences directly from there. This meant that it could return
negative values (except on platforms where "char" is unsigned) if the
input contained bytes >= 128. This would break later parsing in
input.c as the values would be interpreted as having the MP_KEY_DOWN
flag set, which would make the key binding code think a key is held
down (and never released). Fix by changing the buffer type to unsigned
char.
The bug itself was very old, but started triggering visible breakage
more easily after commit 82b8f89bae ("input: rework event reading and
command queuing"). Before that the key values would be passed through
the input.c "key read function" interface, which (mis)interpreted the
negative values as errors from the function, and in most cases
discarded them without much visible effect.
Setting O_NONBLOCK on a file descriptor also affects all other fds
that share the same underlying open file description, and in case of
stdin such sharing is likely. Making stdin nonblocking can also make
stdout nonblocking (they may be the same connection to a terminal),
and it can also affect other processes (in "program1 | program2", the
shell may give the same terminal connection to program1 as stdin and
to program2 as stdout, thus program1 making its stdin nonblocking also
turns program2's stdout nonblocking).
To avoid these problems stop making fd 0 nonblocking. After the
previous commit this should no longer cause problems as long as
select() does not spuriously report the fd as readable.
Move the definitions of all special key codes (those not passed by
ASCII value) to input/keycodes.h. Before they were spread between
osdep/keycodes.h, input/joystick.h, input/mouse.h and input/ar.h, plus
some special values in input.h. This was especially inconvenient as
the codes had to be coordinated to not conflict between the files.
The change requires a bit of ugliness as appleir.c includes
<linux/input.h> which contains various conflicting KEY_* definitions.
Work around this by adding a special preprocessor variable which can
be used to avoid defining these in keycodes.h.
getch2.c did not make stdin non-blocking, and relied on only being
called after select() had shown readability. Stop relying on that
assumption and set stdin to non-blocking mode. Hopefully no relevant
platform has problems with this...
This is necessary at least on POSIX systems since the buffer returned by
nl_langinfo may change its contents with e.g. each setlocale call.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29332 b3059339-0415-0410-9bf9-f77b7e298cf2
The "erase_to_end_of_line" string used to clear the terminal status
line was initialized with the termcap id "cd", which means to clear
all lines below the cursor. Change it to the correct "ce" to clear the
current line.
Usually the status line is on the bottommost line of the terminal so
the behaviour wouldn't differ much. However it did make a difference
when I tested starting MPlayer at the top of a huge gnome-terminal
window so the status line was not at the bottom; in that case clearing
just the current line used less CPU than clearing the part of the huge
window below the status line.
Replace all USE_ prefixes by CONFIG_ prefixes to indicate
options which are configurable.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@27373 b3059339-0415-0410-9bf9-f77b7e298cf2
Keycode length wasn't checked in one case because of missing
parentheses. This was accidentally broken in my previous commit to the
file. Most likely the error had no practical effect; the length checks
are unreliable in any case as they can be satisfied by unrelated
data corresponding to other keypresses.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@24535 b3059339-0415-0410-9bf9-f77b7e298cf2
The Unix version of getch2() could either return an internally buffered
key or do a second-level select() in addition to the input.c one and
then read more data. Change getch2() to always add all read keys with
mplayer_put_key() (like video output window keyboard input does) and
remove the internal select() from the Unix version. Make input.c call
mplayer_get_key() directly.
The primary motivation for this change is to make combining multiple
event sources under one select() easier. Now getch2() only needs to be
called when the corresponding fd is readable, and it will be possible to
handle events from X-based VOs with the same code.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@24149 b3059339-0415-0410-9bf9-f77b7e298cf2
patch replaces '()' for the correct '(void)' in function
declarations/prototypes which have no parameters. The '()' syntax tell
thats there is a variable list of arguments, so that the compiler cannot
check this. The extra CFLAG '-Wstrict-declarations' shows those cases.
Comments about a similar patch applied to ffmpeg:
That in C++ these mean the same, but in ANSI C the semantics are
different; function() is an (obsolete) K&R C style forward declaration,
it basically means that the function can have any number and any types
of parameters, effectively completely preventing the compiler from doing
any sort of type checking. -- Erik Slagter
Defining functions with unspecified arguments is allowed but bad.
With arguments unspecified the compiler can't report an error/warning
if the function is called with incorrect arguments. -- Måns Rullgård
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@17567 b3059339-0415-0410-9bf9-f77b7e298cf2
check for Glibc, not GNU.
patch by Robert Millan <zeratul2@wanadoo.es>
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@12064 b3059339-0415-0410-9bf9-f77b7e298cf2
Rudolf Polzer
wm4
wm4
Uoti Urpala
Uoti Urpala
reimar
diego
Uoti Urpala
uau
rathann
ods15
alex
arpi