I'm using the Links2 console web browser in graphical mode (the "-g" argument), and launching a shell script
that invokes MPlayer from within it. MPlayer works fine. No problem there. The problem, is that I have no
control over the MPlayer process. I would like to be able to exit MPlayer whenever i'd like, without having to
press Ctrl-C. Which terminates both MPlayer and Links2. It seems whenever I input anything on the keyboard,
it affects Links2, rather than MPlayer. Below is my shell script.
Thank you for that. But, it doesn't appear to be working. I think the problem may be that i'm running LInks2 in SDL mode. And I am unable, for some reason, to run it with
If you don't have a console, you won't have a keyboard.
I take it you're running without any window manager or proper console device. The main reason we have those is to share the screen and keyboard with different programs. Operating without means it comes down to whatever SDL driver you're using and whatever it's communicating with.
So you'll probably have to tell us a lot more about what you're doing Sorry.
Ok. First of all, thank you for not being a jerk. Like a lot of people on stackoverflow.com or unix.stackexchange.com.. It's appreciated. I'm actually running this script off of a
Zipit Z2 (a very cool palmtop computer). At the moment, i'm running Debian "Wheezy" on it. With a lot of custom modifications. Anyway... No, I do not run any kind of
window managers or anything GUI-like on it. I use the console on it, for everything. I actually compiled Links2 with an SDL patch. To allow SDL screen rendering. Which is nice,
but, at the same time detrimental. In that, programs like chvt do not work. So, i'm stuck using the current console, or TTY. However you look at it. Ultimately, what i'd like to
achieve, is launching MPlayer from Links2, to watch YouTube videos. It works in its current state, it's just that, like I said, I have no keyboard control over MPlayer at all.
I've done a bit of research, and it seems that the best way to approach this, is to use fifos. I know there has to be an easier/better way than that. I guess redirecting things to STDIN
doesn't work. Probably, again, the SDL issue. So, yes, i'd like to control MPlayer from the current console within Links2. I hope i'm being assertive enough here.
If you need any more information, please don't hesitate to ask me.
SDL is a go-between library which supports a lot of different backends, so it's not that helpful to know you're using SDL. I'm guessing SDL is ultimately using raw framebuffer or something like it here. If you can tell me what exact graphics module SDL is using internally that'd be great, I can look that up and find out if it has any relevant options.
Are you saying chvt doesn't work in links? Or doesn't work in mplayer? Or both?
does chvt work when you run mplayer manually, as opposed to links running it?
mplayer and links should probably be in different virtual terminals. Without a WM, graphics can't really share.
Either way it'll be a kludge, either to shoehorn some sideband input into mplayer, or to push it onto a different terminal and switch your terminal to it.
I have no idea which backend it is using. But, yes, it is using the framebuffer. Links2 is compiled against SDL, which uses the framebuffer device.
chvt doesn't work in Links2, no. Not within Links2 in SDL mode, at least. Yes, it works when running MPlayer manually. Yes, exactly. That's the problem... it doesn't change to another terminal to run MPlayer. That's my problem. I'm currently investigating ways of working around this SDL limitation, which i'm assuming it is. I'm trying to get Links2 to run in "fbdev" mode, as opposed to SDL mode. DirectFB is not an option, because it requires that the screen be rotated. Which the version i'm using doesn't support. And, it's too much of a hassle to compile the new/updated source code. I hope this information is sufficient.
Not an SDL limitation, a side-effect of the way the keyboard and screen is being used. Which depends on what backend is being used. Sorry if I sound like a broken record but that's a really important unknown.
A link to the patch you used to get Links using SDL would also be good. I've a passing familiary with SDL and can check if I see anything obviously wrong.
That you're compiling is also useful. We might add lines to answer the question if we really can't find it out any other way.
Okay, that gives me enough information to research. I think you're using libsdl's fbcon. According to your patch there should be debug information being printed into a stderr.txt somewhere.
Looking at the source code, libSDL's fbcon module sets raw mode on the keyboard, which according to this prevents not just ctrl-alt-f4 but the chvt call itself from operating. Preventing this will probably stop Links from working.
Hunting for SDL_getenv - the usual transport for special-case SDL backend hacks - in fbcon's source shows a few options related to setting resolution and mouse device, but nothing relevant to keyboard. It just grabs it in raw mode - as it should for a graphical program - and that's it.
So, I think this means that Links needs to call SDL_QuitSubSystem(SDL_INIT_EVENTS) before shelling out to an external command, and SDL_InitSubSystem(SDL_INIT_EVENTS) after returning from an external command, to place the keyboard into normal mode and allow chvt to happen when using the fbcon module.
Sorry.