SDL 1.3 framebuffer console support

SDL 1.3 doesn’t currently have framebuffer console support.

Does anyone care? Does anyone care enough to work on it?

See ya!–
? ? -Sam Lantinga, Founder and President, Galaxy Gameworks LLC

I would be sad to see support for this get left behind.On Sun, Jul 18, 2010 at 4:21 AM, Sam Lantinga wrote:

SDL 1.3 doesn’t currently have framebuffer console support.

Does anyone care? ?Does anyone care enough to work on it?

See ya!

? ? -Sam Lantinga, Founder and President, Galaxy Gameworks LLC


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


http://codebad.com/

SDL 1.3 doesn’t currently have framebuffer console support.

Does anyone care? ?Does anyone care enough to work on it?

See ya!

I won’t miss it. Does anyone use it anymore?

Bob PendletonOn Sun, Jul 18, 2010 at 3:21 AM, Sam Lantinga wrote:


? ? -Sam Lantinga, Founder and President, Galaxy Gameworks LLC


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


±----------------------------------------------------------

SDL 1.3 doesn’t currently have framebuffer console support.

Does anyone care? Does anyone care enough to work on it?

See ya!

I won’t miss it. Does anyone use it anymore?

Bob Pendleton

As a lowest common denominator kind of thing, it’d be sad to see it go.
There’s also a chance the embedded world would hate to see it go. But…
for the life of me… I can’t think of anyone that actually uses it…

-WillOn Sun, Jul 18, 2010 at 9:01 PM, Bob Pendleton wrote:

On Sun, Jul 18, 2010 at 3:21 AM, Sam Lantinga wrote:

As a lowest common denominator kind of thing, it’d be sad to see it go. There’s

also a chance the embedded world would hate to see it go. But… for the life
of me… I can’t think of anyone that actually uses it…

-Will

Why would the embedded world miss it? They’ve all got OpenGL ES.

Why would the embedded world miss it? They’ve all got OpenGL ES.

Ya missed “lowest common” :).

Is there a poll out there for how common non-3d devices are (from PC’s with
old video to something more PDA-esque) ?

Granted, PDA-esque stuff prolly won’t be running linux…

And I can’t think of anything PC related since the advent of the P4 class
systems that doesn’t have integrated 3D of some kind or another…

Maybe I’ve disproven my own original post now ?

-Will

Granted, PDA-esque stuff prolly won’t be running linux…

Actually… do any of the linuxy / open sourcy hand helds (gpx i think is
name of one, pandora another ?) run off a frame buffer device ? do they even
use sdl ?

do any ARM or SoC stuff come with only a frame buffer only device these days
?

-Will

Why would the embedded world miss it? They’ve all got OpenGL ES.

Ya missed “lowest common” :).

Is there a poll out there for how common non-3d devices are (from PC’s with old

video to something more PDA-esque) ?

Granted, PDA-esque stuff prolly won’t be running linux…

And I can’t think of anything PC related since the advent of the P4 class
systems that doesn’t have integrated 3D of some kind or another…

Maybe I’ve disproven my own original post now ?

See what I mean? When you think about it, in today’s world, OpenGL/GL ES is
the lowest common denominator!>From: Will Langford

Subject: Re: [SDL] SDL 1.3 framebuffer console support

Is there a poll out there for how common non-3d devices are (from PC’s with
old video to something more PDA-esque) ?

Granted, PDA-esque stuff prolly won’t be running linux…

Um, a helluva lot of industrial thingies are running Linux and have no
(and need no) 3D HW. Touchscreen, an ARM core running at a few hundred
megs with loads of on-board peripherals and Linux => a device that needs
relatively low power, free OS, can be rather user friendly and quite
simple to write easy to device drivers for the specialised industrial
hardware. Designers like that. You don’t depend on an SW vendor, no
royalty, easy to find people who can program for it. Managers like that.
So Linux is very welcome. 3D hardware is not needed for the device to be
functional, user friendly and astethically pleasing. Therefore nobody is
willing to afford the board real estate and/or power and/or cost
associated with the 3D HW.

Mobile phones and handheld game consoles are of course a much bigger
market for a very different audience. However, in the industrial niche
embedded systems with a colour LCD and touchscreen do not automatically
mean 3D graphics.

Zoltan

Actually… do any of the linuxy / open sourcy hand helds (gpx i think is
name of one, pandora another ?) run off a frame buffer device ? do they even
use sdl ?

Yes. Yes.

do any ARM or SoC stuff come with only a frame buffer only device these days
?

Yes.

Zoltan

Is there a poll out there for how common non-3d devices are (from PC’s with
old video to something more PDA-esque) ?

Granted, PDA-esque stuff prolly won’t be running linux…

Um, a helluva lot of industrial thingies are running Linux and have no
(and need no) 3D HW. Touchscreen, an ARM core running at a few hundred
megs with loads of on-board peripherals and Linux => a device that needs
relatively low power, free OS, can be rather user friendly and quite
simple to write easy to device drivers for the specialised industrial
hardware. Designers like that. You don’t depend on an SW vendor, no
royalty, easy to find people who can program for it. Managers like that.
So Linux is very welcome. 3D hardware is not needed for the device to be
functional, user friendly and astethically pleasing. Therefore nobody is
willing to afford the board real estate and/or power and/or cost
associated with the 3D HW.

Mobile phones and handheld game consoles are of course a much bigger
market for a very different audience. However, in the industrial niche
embedded systems with a colour LCD and touchscreen do not automatically
mean 3D graphics.

Very good point. Are they using a graphic interface or using something
like ncurses? I ask because, as you said, these device provide minimal
memory and often do not include a full frame buffer, just s simple
character display.On Sun, Jul 18, 2010 at 11:05 PM, wrote:

Zoltan


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


±----------------------------------------------------------

I still use embedded CPUs with no 3d. All the ones I’m aware of with
an actual video device have a framebuffer, the ones I’ve seen with
only character displays tend to have LCD status displays (very small
ones) running from a serial port instead of as a “video” device.

If SDL 1.3 supports framebuffers, I’m likely to use it for a couple
upcoming projects, although I admit I probably don’t know enough about
video hardware to contribute much to making drivers work. If 1.3
doesn’t support them, I’d be likely to use 1.2.x instead, if I could.

Do framebuffer programs benefit from any features of SDL 1.3?

Jonny DOn Mon, Jul 19, 2010 at 11:12 AM, Justin Coleman wrote:

I still use embedded CPUs with no 3d. All the ones I’m aware of with
an actual video device have a framebuffer, the ones I’ve seen with
only character displays tend to have LCD status displays (very small
ones) running from a serial port instead of as a “video” device.

If SDL 1.3 supports framebuffers, I’m likely to use it for a couple
upcoming projects, although I admit I probably don’t know enough about
video hardware to contribute much to making drivers work. If 1.3
doesn’t support them, I’d be likely to use 1.2.x instead, if I could.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Bob Pendleton wrote:> On Sun, Jul 18, 2010 at 11:05 PM, wrote:

Is there a poll out there for how common non-3d devices are (from PC’s with
old video to something more PDA-esque) ?
[snip snip]

Mobile phones and handheld game consoles are of course a much bigger
market for a very different audience. However, in the industrial niche
embedded systems with a colour LCD and touchscreen do not automatically
mean 3D graphics.

Very good point. Are they using a graphic interface or using something
like ncurses? I ask because, as you said, these device provide minimal
memory and often do not include a full frame buffer, just s simple
character display.

Larger panels (e.g. RGB 320x240) have a controller that use
VGA-like lines with HSYNC and VSYNC, so the system MCU holds a
framebuffer and usually there is a graphics peripheral on-chip.
(Or generate the signals on-the-fly like in Propeller chips.)

Cheaper mobile phones have LCDs that often are chip-on-glass that
holds a framebuffer. The MCU tells the chip what parts of the
memory to change, so it doesn’t actually need a framebuffer.

Alphanumeric LCDs generally accepts ASCII-like character codes
(with 8 custom character patterns), has its own framebuffer (or
display memory).

Not sure if there are other architectures, but these are the most
common in embedded systems, I think.


Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia

Isn’t the 1.3 API still in flux?On Mon, Jul 19, 2010 at 11:25 AM, Jonathan Dearborn wrote:

Do framebuffer programs benefit from any features of SDL 1.3?
Jonny D


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

The API may be, but the core features are stable.

Jonny DOn Mon, Jul 19, 2010 at 2:46 PM, Jeremiah wrote:

On Mon, Jul 19, 2010 at 11:25 AM, Jonathan Dearborn <@Jonathan_Dearborn> wrote:

Do framebuffer programs benefit from any features of SDL 1.3?
Jonny D


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Isn’t the 1.3 API still in flux?


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Very good point. Are they using a graphic interface or using something
like ncurses? I ask because, as you said, these device provide minimal
memory and often do not include a full frame buffer, just s simple
character display.

Well, we use graphics. Handheld device, should be designed for
tradesman. Minimal amount of text, icons, clear interface, touchscreen.
The memory is pretty low, 64M, but a 800x600 16bit framebuffer is not
much of a problem. Probably due to the smartphones, reasonable
resolution colour TFTs came down in price by a huge amount. A SoC chip
with an ARM9 core, LCD/SDRAM/NAND/NOR controllers plus a handful of
peripherals on-chip is also quite affordable. However, it is still not
a desktop class system, so you don’t want to run X11, you use a
stripped-down kernel (and system). SDL is perfect for these systems
because it provides all the graphics primitives, small and efficient.
Plus it handles sound as well, which has little practical use but is
(almost) free and is a neat feature to show off when you want to have
something that the competition doesn’t :wink:

Regards,

Zoltan

Ok, that makes sense. This gets us back to a discussion that Sam and I
had several years ago. SDL 1.3 supports multiple windows. Is there any
point in porting 1.3 to systems that do not have multiple window
support? IIRC we decided that on the kind of system you are describing
we would just support one window with a fixed size and location. If
the programmer asks for anything else he would get an error. So, it
looks to me like 1.3 should retain framebuffer support.

But, I’m of the opinion that if retaining frame buffer support limits
1.3 on other platforms then we need to drop it and tell people to use
1.2 for the use you describe.

Bob PendletonOn Tue, Jul 20, 2010 at 7:54 AM, Zolt?n K?csi wrote:

Very good point. Are they using a graphic interface or using something
like ncurses? I ask because, as you said, these device provide minimal
memory and often do not include a full frame buffer, just s simple
character display.

Well, we use graphics. Handheld device, should be designed for
tradesman. Minimal amount of text, icons, clear interface, touchscreen.
The memory is pretty low, 64M, but a 800x600 16bit framebuffer is not
much of a problem. Probably due to the smartphones, reasonable
resolution colour TFTs came down in price by a huge amount. A SoC chip
with an ARM9 core, LCD/SDRAM/NAND/NOR controllers plus a handful of
peripherals on-chip is also quite affordable. However, it is still not
a desktop class system, so you don’t want to run X11, you use a
stripped-down kernel (and system). SDL is perfect for these systems
because it provides all the graphics primitives, small and efficient.
Plus it handles sound as well, which has little practical use but is
(almost) free and is a neat feature to show off when you want to have
something that the competition doesn’t :wink:

Regards,

Zoltan


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


±----------------------------------------------------------

But, I’m of the opinion that if retaining frame buffer support limits
1.3 on other platforms then we need to drop it and tell people to use
1.2 for the use you describe.

Yes, I agree with that. As long as 1.2 is maintained at least as much as
remaining compilable (the way gcc keeps changing it’s not a
given…) then 1.2 should be enough for embedded devices.

Zoltan