gnuplot-beta

[patch] SVGAlib fixes

[David K. <dvd...@gm...>]

Hi,

I've been working on an graphics-capable GNUplot port for OpenWrt [1],
for use with the open-hardware NanoNote "PDA" [2].

The NanoNote only has 32MB RAM so the OpenWrt image we use does not come
with an X-Server, insead everything is directly drawn onto the
framebuffer (Gtk and Qt can work this way).

For GNUplot I had to fall back on using a port of SVGAlib that uses the
Framebuffer for text/graphics mode switching to reliably work without
messing up console input.

The first attached single-line patch makes Gnuplot's 'linux.trm' driver
work with all SVGAlib video modes, not only 16 and 256-color modes (the
NanoNote only supports G320x240x16M32).

The second patch fixes selection of the terminal type when svgalib
support is compiled in.  Currently it wrongly selects 'vgagl' over
'linux' even when 'vgagl' driver is not compiled in due to missing
lib3dkit.

cheers,

David

[1] http://projects.qi-hardware.com/index.php/p/openwrt-packages/source/tree/master/gnuplot-gfx
[2] http://en.qi-hardware.com/wiki/Ben_NanoNote
-- 
GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg
Fingerprint: B17A DC95 D293 657B 4205  D016 7DEF 5323 C174 7D40

Re: [patch] SVGAlib fixes

[Ethan M. <merritt@u.washington.edu>]

On Sunday, January 09, 2011 03:25:53 am David Kuehling wrote:
> Hi,
> 
> I've been working on an graphics-capable GNUplot port for OpenWrt [1],
> for use with the open-hardware NanoNote "PDA" [2].
> 
> The NanoNote only has 32MB RAM so the OpenWrt image we use does not come
> with an X-Server, insead everything is directly drawn onto the
> framebuffer
> 
> For GNUplot I had to fall back on using a port of SVGAlib that uses the
> Framebuffer for text/graphics mode switching to reliably work without
> messing up console input.

I am happy to accept the patches to term.c and linux.trm,
but ...

 >(Gtk and Qt can work this way).

Wouldn't it be more interesting to see if the Qt terminal driver
in gnuplot CVS can be used on this device?  It was my understanding that
it was developed partly to support the sort of device you describe.

I haven't seen much discussion or feedback about qt.trm, so maybe people
haven't noticed it yet.  On a normal desktop machine it doesn't seem to have
any particular advantage over the wxgtk-based wxt.trm, but on a small
device it might be an entirely different story.

	Ethan

> The first attached single-line patch makes Gnuplot's 'linux.trm' driver
> work with all SVGAlib video modes, not only 16 and 256-color modes (the
> NanoNote only supports G320x240x16M32).
> 
> The second patch fixes selection of the terminal type when svgalib
> support is compiled in.  Currently it wrongly selects 'vgagl' over
> 'linux' even when 'vgagl' driver is not compiled in due to missing
> lib3dkit.
> 
> cheers,
> 
> David
> 
> [1] http://projects.qi-hardware.com/index.php/p/openwrt-packages/source/tree/master/gnuplot-gfx
> [2] http://en.qi-hardware.com/wiki/Ben_NanoNote

Re: [patch] SVGAlib fixes

[David K. <dvd...@gm...>]

>>>>> "Ethan" == Ethan Merritt <merritt@u.washington.edu> writes:

> I am happy to accept the patches to term.c and linux.trm, but ...

>> (Gtk and Qt can work this way).

> Wouldn't it be more interesting to see if the Qt terminal driver in
> gnuplot CVS can be used on this device?  It was my understanding that
> it was developed partly to support the sort of device you describe.

> I haven't seen much discussion or feedback about qt.trm, so maybe
> people haven't noticed it yet.  On a normal desktop machine it doesn't
> seem to have any particular advantage over the wxgtk-based wxt.trm,
> but on a small device it might be an entirely different story.

Actually I gave qt a try with PLplot, but it kept crashing, so when I
gave up and started a GNUplot port, I didn't bother to test the qt
driver.  Also Qt seems to start some kind of a mini window manager
(called QWS) when running directly on the console, so startup time and
memory usage are nowhere close to SVGAlib.  Especially considering that
I want to use gnuplot as a plotting backend for Octave, memory footprint
needs to stay down (only 32MB RAM, no swap on the Nanonote).

cheers,

David
-- 
GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg
Fingerprint: B17A DC95 D293 657B 4205  D016 7DEF 5323 C174 7D40