Release Live system info

[Linux-SWAT]

May i ask for a change in the Slackware detection for the next release ?

ktsuss uses 50% cpu, i checked the package maintenance for an update, and it's now removed and marked as broken which sounds good to me.

So can you change the

ktsuss -m "$MSG" ./liveinfo

into

gksu ./liveinfo

please ?

Sorry for the inconvenience :/

 

[_wb_]

It's really nice to be able to draw on the hardware overlay. Your code does the drawing in a low-level way though. It would be easier to use (for me at least) if I could use SDL. Would that be possible? E.g. have some environment variable (SDL_OMAP_OVERLAY or whatever) that influences whether the screen surface is the main layer or the overlay layer.

 

[ptitSeb]

What would be interesting also (in my point of view at least) is to have the X11 Mouse Cursor drawn in this layer instead of the standard one (may be with some emulation layer inside glshim to trap the cursor drawing routines). That will solve all the blinking cursor issue with most X11/OPenGL soft & games.

 

[notaz]

May i ask for a change in the Slackware detection for the next release ?

If I don't forget..

It's really nice to be able to draw on the hardware overlay. Your code does the drawing in a low-level way though. It would be easier to use (for me at least) if I could use SDL. Would that be possible? E.g. have some environment variable (SDL_OMAP_OVERLAY or whatever) that influences whether the screen surface is the main layer or the overlay layer.

There is SDL_FBDEV, but I haven't tested it. SDL will probably mess up when tv-out is enabled, or will break tv-out itself if you use that overlay, so I don't recommend using SDL for it.

What would be interesting also (in my point of view at least) is to have the X11 Mouse Cursor drawn in this layer instead of the standard one (may be with some emulation layer inside glshim to trap the cursor drawing routines). That will solve all the blinking cursor issue with most X11/OPenGL soft & games.

It's quite a waste to use the whole layer just for the cursor. Also, it will break tv-out (or tv-out will break it).

 

[ptitSeb]

What would be interesting also (in my point of view at least) is to have the X11 Mouse Cursor drawn in this layer instead of the standard one (may be with some emulation layer inside glshim to trap the cursor drawing routines). That will solve all the blinking cursor issue with most X11/OPenGL soft & games.

It's quite a waste to use the whole layer just for the cursor. Also, it will break tv-out (or tv-out will break it).

I agree. But the layer doesn't have to be exclusive to the mouse cursor. And yes, it should not be used when TVOut is active.

 

[notaz]

Ok update posted. There is now a config file (created in appdata on first run) where you can specify the overlay's position.

You can also send USR1 signal to show/hide the overlay, so you can bind "killall -USR1 liveinfo" command to do it. For example, pndevmapper can be used for this:


sudo su
echo '#!/bin/sh' > /home/root/livetoggle.sh
echo 'killall -USR1 liveinfo' >> /home/root/livetoggle.sh
chmod +x /home/root/livetoggle.sh

# now edit /etc/pandora/conf/eventmap and add "f12 /home/root/livetoggle.sh" in [keys] section, replace f12 if needed
# then restart pndevmapper
/etc/init.d/pndevmapperd-init stop
/etc/init.d/pndevmapperd-init start
You can also show custom numbers on the overlay too, maybe I'll just quote readme here:

Showing custom fields and alternative control

---------------------------------------------

There is a tool called 'custom' included inside of .pnd, it can be used

to also send commands and display custom fields. The code is included

inside the .pnd and can be integrated in other programs, it's simple

communication over local/unix sockets.

Any command containing a semicolon ":" is interpreted as a field to

display on screen. For example, running

./custom "fps: 60"

will show that string on screen. There is no removal command, the

string will time out by itself.

Other understood commands are:

quit - self explanatory

hide

show

poke - if hidden, show up; if visible, exit

And the code:

Spoiler

#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/un.h>
#include <unistd.h>

int main(int argc, char *argv[])
{
  static const char socket_name[] = "\0liveinfo";
  struct sockaddr_un sun;
  int sock;
  int ret;

  if (argv[1] == NULL) {
    fprintf(stderr, "usage:\n%s \"label: value\"\n", argv[0]);
    return 1;
  }

  sock = socket(PF_UNIX, SOCK_DGRAM, 0);
  if (sock == -1) {
    perror("socket PF_UNIX");
    return 1;
  }

  memset(&sun, 0, sizeof(sun));
  sun.sun_family = AF_UNIX;
  memcpy(sun.sun_path, socket_name, sizeof(socket_name));

  ret = sendto(sock, argv[1], strlen(argv[1]), 0,
    (struct sockaddr *)&sun, sizeof(sun));
  if (ret < 0) {
    perror("sendto");
    return 1;
  }

  close(sock);
  return 0;
}

 

[rygD]

Thanks a ton.  I will take a look in a bit.

 

[ptitSeb]

Thanks Notaz. That super easy to use!

I have put automatic detection of LiveInfo in glshim, so it display fps automaticly. I'll updates my things soon .

For the gles things, I'll probably do it also, but later.

 

[lunixbochs]

Thanks Notaz. That super easy to use!

I have put automatic detection of LiveInfo in glshim, so it display fps automaticly. I'll updates my things soon .

For the gles things, I'll probably do it also, but later.

You're a bit late on that

I'm planning to move EGL to generated runtime code instead of dynamically linked as well (so I can run it on systems without EGL), so I can add the fps counter to EGL then.

What are you using to call custom?

 

[ptitSeb]

Thanks Notaz. That super easy to use!

I have put automatic detection of LiveInfo in glshim, so it display fps automaticly. I'll updates my things soon .

For the gles things, I'll probably do it also, but later.

You're a bit late on that

I'm planning to move EGL to generated runtime code instead of dynamically linked as well (so I can run it on systems without EGL), so I can add the fps counter then.

What are you using to call custom?

I just put the code inside glxSwapBuffer, same place (and same code) as the current show_fps, and added the open of the sock inside scan_env() (and if sock=-1, that means no liveinfo), so if sock>-1, I use it to display the string (that should be 10 characters).

(about the gles things, I was thinking of my gles port, where I have to put the code on a one by one game basis. Not sure I understood what your are planning to do with EGL)

 

[lunixbochs]

No, I mean the literal method you used for command execution of "/mnt/utmp/liveinfo/custom", or do you connect to the unix socket yourself?

 

[ptitSeb]

No, I mean the literal method for actual command execution of "/mnt/utmp/liveinfo/custom"

Yes,but you don't need to call it. You can just open the socket and send command.

 

[lunixbochs]

k, I'm throwing a global utility function in for sending stuff to it

Also, sock != -1 just means you were able to make a valid unix socket. (Looks like you'll get "sendto: connection refused" if it's not running.)

Thanks notaz!

 

[ptitSeb]

k, I'm throwing a global utility function in for sending stuff to it

Also, sock != -1 just means you were able to make a valid unix socket. (Looks like you'll get "sendto: connection refused" if it's not running.)

Thanks notaz!

Hmm, yes, I'll update my detection routine to also send something and test for the return value.

 

[Linux-SWAT]

Ahh, my gksu takes no argument, otherwise it fails !

gksu ./liveinfo

:/

 

[notaz]

Ahh, my gksu takes no argument, otherwise it fails !

gksu ./liveinfo

:/

Updated..
Maybe you should just make a gksudo binary in your distro which is really just a script with something like this:

#!/bin/sh
while test -n "$1"; do
  arg="$1"
  shift
  c=`echo "$arg" | cut -c1`
  if [ "$c" = "-" ]; then
    case $arg in
      "-u"|"--user"|"-D"|"--description"|"-m"|"--message")
        shift;;
    esac
  else
    cmd=$arg
  fi
done

gksu "$cmd"

This way no slack detection in pnd is needed.

 

[_jr_]

Liveinfo runs great, but while it is running the mplayer binary from the codec pack doesn't display anything and instead spews loads of

X11 error: BadAtom (invalid Atom parameter)

The player from the smplayer2 pnd works, though the liveinfo overlay isn't transparent any longer but gets a solid greenish backgroud.

 

[rygD]

Liveinfo runs great, but while it is running the mplayer binary from the codec pack doesn't display anything and instead spews loads of


X11 error: BadAtom (invalid Atom parameter)
The player from the smplayer2 pnd works, though the liveinfo overlay isn't transparent any longer but gets a solid greenish backgroud.

Out of curiosity, what happens if you toggle it off in either of those situations?

 

[_wb_]

It's really nice to be able to draw on the hardware overlay. Your code does the drawing in a low-level way though. It would be easier to use (for me at least) if I could use SDL. Would that be possible? E.g. have some environment variable (SDL_OMAP_OVERLAY or whatever) that influences whether the screen surface is the main layer or the overlay layer.

There is SDL_FBDEV, but I haven't tested it. SDL will probably mess up when tv-out is enabled, or will break tv-out itself if you use that overlay, so I don't recommend using SDL for it.

Would it be hard to modify your omapfb SDL driver to use the overlay framebuffer instead of the main one? It would be nice if I could make Pandora System Info draw its stuff on an overlay.

How does the overlay know what is transparent? Is it RGBA? If it can do semi-transparent stuff (arbitrary alpha values) then it could be used for pretty neat stuff.

 

[notaz]

Would it be hard to modify your omapfb SDL driver to use the overlay framebuffer instead of the main one? It would be nice if I could make Pandora System Info draw its stuff on an overlay.

FYI it's already using an overlay, and you can also make it transparent, but SDL doesn't have API calls for that (I think? I'm not a fan of SDL so don't know too much). There are 3 layers in total, Xorg/SGX uses the first that can't scale, SDL/some emus use the second one that can scale and be transparent, and there is 3rd one that's supposed to be reserved and requires root, also used for TV-out.

How does the overlay know what is transparent? Is it RGBA? If it can do semi-transparent stuff (arbitrary alpha values) then it could be used for pretty neat stuff.

Color keying - you specify transparent color. There is no support for alpha.