Does QNX6 support anything like Linux’s Framebuffer Console? The problem is
I need more screen real-estate in a standard console (not a pterm). 80x25
just doesn’t cut it. Reason: We are using Ncurses and would like to use
some text based widgets (buttonboxes, etc.)
I know QNX4 allowed you to change the font, but it looked terrible. Unless
QNX6 does things differently (i.e. decent looking font at 160x50), this is
not a viable option.
Thanks in advance.
–
William Davis
QNX4 was rather advanced in that department compared to QNX6 
The answer is no. You can write your own framebuffer driver though, or port
Linux one… should not be that hard.
“William Davis” <bill.davis@fkilogistex.com> wrote in message
news:bp0n5o$b6p$1@inn.qnx.com…
Does QNX6 support anything like Linux’s Framebuffer Console? The problem
is
I need more screen real-estate in a standard console (not a pterm). 80x25
just doesn’t cut it. Reason: We are using Ncurses and would like to use
some text based widgets (buttonboxes, etc.)I know QNX4 allowed you to change the font, but it looked terrible.
Unless
QNX6 does things differently (i.e. decent looking font at 160x50), this is
not a viable option.Thanks in advance.
–
William Davis
Thank you Igor. That was what I was afraid of. I do appreciate the
response however.
Igor Kovalenko wrote:
QNX4 was rather advanced in that department compared to QNX6 >
The answer is no. You can write your own framebuffer driver though, or
port Linux one… should not be that hard.“William Davis” <> bill.davis@fkilogistex.com> > wrote in message
news:bp0n5o$b6p$> 1@inn.qnx.com> …
Does QNX6 support anything like Linux’s Framebuffer Console? The problem
is
I need more screen real-estate in a standard console (not a pterm).
80x25
just doesn’t cut it. Reason: We are using Ncurses and would like to use
some text based widgets (buttonboxes, etc.)I know QNX4 allowed you to change the font, but it looked terrible.
Unless
QNX6 does things differently (i.e. decent looking font at 160x50), this
is not a viable option.Thanks in advance.
–
William Davis
–
William Davis
William Davis <bill.davis@fkilogistex.com> wrote:
Does QNX6 support anything like Linux’s Framebuffer Console? The problem is
I need more screen real-estate in a standard console (not a pterm). 80x25
just doesn’t cut it. Reason: We are using Ncurses and would like to use
some text based widgets (buttonboxes, etc.)
Nope. Although I have been thinking of showing people how to do it with
Photon. Nothing stopping people from exploiting the fact that pterm is
built with a PtTerminal widget and that photon already provides a nice
accelerated graphics mode.
chris
–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
“Chris McKillop” <cdm@qnx.com> wrote in message
news:bp2rsn$k87$1@nntp.qnx.com…
William Davis <> bill.davis@fkilogistex.com> > wrote:
Does QNX6 support anything like Linux’s Framebuffer Console? The
problem is
I need more screen real-estate in a standard console (not a pterm).
80x25
just doesn’t cut it. Reason: We are using Ncurses and would like to use
some text based widgets (buttonboxes, etc.)
Nope. Although I have been thinking of showing people how to do it with
Photon. Nothing stopping people from exploiting the fact that pterm is
built with a PtTerminal widget and that photon already provides a nice
accelerated graphics mode.
Isn’t it kind of overkill… Even though it’s accelerated graphics it still
way heavier then handling text.
To be blunt Chris this sounds like a Microsoft solution, where you throw a
complexe solution at a simple problem.
I know a lot of QNX4 system where each program prints into its own text
console (for a total of over 20 consoles in some cases with the help of
Dev.ditto) and moving this to gfx would simply bring the system to its
knees).
chris
–
Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
Isn’t it kind of overkill… Even though it’s accelerated graphics it still
way heavier then handling text.To be blunt Chris this sounds like a Microsoft solution, where you throw a
complexe solution at a simple problem.
Not at all. It is a generic solution that will work on systems that don’t
have a legacy text-mode system (ie: ARM, PowerPC and MIPS based platforms).
In fact, the vast majority of Linux systems use video mode and have kernel
level accelerated drivers for doing just this sort of thing. It’s how
they handle unicode consoles, inline graphics and complex fonts. And
the original poster actually asked if we had something like that.
I know a lot of QNX4 system where each program prints into its own text
console (for a total of over 20 consoles in some cases with the help of
Dev.ditto) and moving this to gfx would simply bring the system to its
knees).
I really don’t think so. At least, not due to the number of consoles.
There is no difference in CPU usage between printing to a PtTerminal widget
that isn’t the current one being displayed and printing to /dev/con1.
There will be more CPU usage for the single terminal that is the current
terminal but having 1 or 20 doesn’t matter.
chris
–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
William Davis <bill.davis@fkilogistex.com> wrote:
Chris,
You mentioned there are some tricks to doing this in Photon. Could you
share this information?Prior to my post I played with pterm. I noticed that a pterm would allow
you modify how many rows and columns…but all that seemed to do was add a
scrollbar and cause my pterm to extend off the bottom of the screen.
Scrollbar? Are you sure you are using pterm? It doesn’t support scroll bars.
The only trick is to know how to strip photon down to it’s bare min. size and
to make a pterm-style app that doesn’t have title bars or borders and always
starts maximized. But the stripping down is only important if you have
disk/flash space restrictions.
chris
–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
Chris,
You mentioned there are some tricks to doing this in Photon. Could you
share this information?
Prior to my post I played with pterm. I noticed that a pterm would allow
you modify how many rows and columns…but all that seemed to do was add a
scrollbar and cause my pterm to extend off the bottom of the screen.
I appreciate everyone’s feedback. Thanks.
Chris McKillop wrote:
Isn’t it kind of overkill… Even though it’s accelerated graphics it
still way heavier then handling text.To be blunt Chris this sounds like a Microsoft solution, where you throw
a complexe solution at a simple problem.
Not at all. It is a generic solution that will work on systems that don’t
have a legacy text-mode system (ie: ARM, PowerPC and MIPS based
platforms). In fact, the vast majority of Linux systems use video mode and
have kernel
level accelerated drivers for doing just this sort of thing. It’s how
they handle unicode consoles, inline graphics and complex fonts. And
the original poster actually asked if we had something like that. >
I know a lot of QNX4 system where each program prints into its own text
console (for a total of over 20 consoles in some cases with the help of
Dev.ditto) and moving this to gfx would simply bring the system to its
knees).
I really don’t think so. At least, not due to the number of consoles.
There is no difference in CPU usage between printing to a PtTerminal
widget that isn’t the current one being displayed and printing to
/dev/con1. There will be more CPU usage for the single terminal that is
the current terminal but having 1 or 20 doesn’t matter.chris
–
William Davis
“Chris McKillop” <cdm@qnx.com> wrote in message
news:bp340d$r8a$1@nntp.qnx.com…
Isn’t it kind of overkill… Even though it’s accelerated graphics it
still
way heavier then handling text.To be blunt Chris this sounds like a Microsoft solution, where you throw
a
complexe solution at a simple problem.
Not at all. It is a generic solution that will work on systems that don’t
have a legacy text-mode system (ie: ARM, PowerPC and MIPS based
platforms).
In fact, the vast majority of Linux systems use video mode and have kernel
level accelerated drivers for doing just this sort of thing. It’s how
they handle unicode consoles, inline graphics and complex fonts. And
the original poster actually asked if we had something like that. >
I know a lot of QNX4 system where each program prints into its own text
console (for a total of over 20 consoles in some cases with the help of
Dev.ditto) and moving this to gfx would simply bring the system to its
knees).
I really don’t think so. At least, not due to the number of consoles.
There is no difference in CPU usage between printing to a PtTerminal
widget
that isn’t the current one being displayed and printing to /dev/con1.
There will be more CPU usage for the single terminal that is the current
terminal but having 1 or 20 doesn’t matter.
Ok thanks for the info.
chris
–
Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
“Chris McKillop” <cdm@qnx.com> wrote in message
news:bp340d$r8a$1@nntp.qnx.com…
Isn’t it kind of overkill… Even though it’s accelerated graphics it
still
way heavier then handling text.To be blunt Chris this sounds like a Microsoft solution, where you throw
a
complexe solution at a simple problem.
Not at all. It is a generic solution that will work on systems that don’t
have a legacy text-mode system (ie: ARM, PowerPC and MIPS based
platforms).
The ‘least common denominator’ approach for multi-platform support is
convinient indeed, but does not bode well for competitiveness. People who
are on a platform X won’t have much comfort in knowing that feature ‘xyz’ is
not supported because none of other platfoms have it.
In fact, the vast majority of Linux systems use video mode and have kernel
level accelerated drivers for doing just this sort of thing. It’s how
they handle unicode consoles, inline graphics and complex fonts. And
the original poster actually asked if we had something like that. >
Don’t forget however that Linux does have a framebuffer driver and usable
console-mode features. Photon-based approach only really works for a local
VGA monitor, which is rather limiting. I find myself using telnet and serial
consoles all the time with embedded targets.
I really don’t like saying that, but looks like Linux folks keep adding
features while QNX keeps coming up with excuses. You know how that ends,
don’t you
– igor
“Igor Kovalenko” <kovalenko@attbi.com> ha scritto nel messaggio
news:bp7800$qci$1@inn.qnx.com…
“Chris McKillop” <> cdm@qnx.com> > wrote in message
news:bp340d$r8a$> 1@nntp.qnx.com> …Isn’t it kind of overkill… Even though it’s accelerated graphics it
still
way heavier then handling text.To be blunt Chris this sounds like a Microsoft solution, where you
throw
a
complexe solution at a simple problem.
Not at all. It is a generic solution that will work on systems that
don’t
have a legacy text-mode system (ie: ARM, PowerPC and MIPS based
platforms).The ‘least common denominator’ approach for multi-platform support is
convinient indeed, but does not bode well for competitiveness. People who
are on a platform X won’t have much comfort in knowing that feature ‘xyz’
is
not supported because none of other platfoms have it.In fact, the vast majority of Linux systems use video mode and have
kernel
level accelerated drivers for doing just this sort of thing. It’s how
they handle unicode consoles, inline graphics and complex fonts. And
the original poster actually asked if we had something like that. >
Don’t forget however that Linux does have a framebuffer driver and usable
console-mode features. Photon-based approach only really works for a local
VGA monitor, which is rather limiting. I find myself using telnet and
serial
consoles all the time with embedded targets.I really don’t like saying that, but looks like Linux folks keep adding
features while QNX keeps coming up with excuses. You know how that ends,
don’t you >– igor
This is a very long story but QSSL is very proud of this…
Don’t forget however that Linux does have a framebuffer driver and usable
console-mode features. Photon-based approach only really works for a local
VGA monitor, which is rather limiting. I find myself using telnet and serial
consoles all the time with embedded targets.I really don’t like saying that, but looks like Linux folks keep adding
features while QNX keeps coming up with excuses. You know how that ends,
don’t you >
I don’t get it. What about a Linux serial device or telnet session makes
it better then a Neutrino one? Plus, if one went the route of having consoles
via Photon, you get nice remote access to your main console from Windows.
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
“Chris McKillop” <cdm@qnx.com> wrote in message
news:bpabel$8al$1@nntp.qnx.com…
Don’t forget however that Linux does have a framebuffer driver and
usable
console-mode features. Photon-based approach only really works for a
local
VGA monitor, which is rather limiting. I find myself using telnet and
serial
consoles all the time with embedded targets.I really don’t like saying that, but looks like Linux folks keep adding
features while QNX keeps coming up with excuses. You know how that ends,
don’t you >
I don’t get it. What about a Linux serial device or telnet session makes
it better then a Neutrino one?
The problem is not with telnet/serial, it is with the console. You can run
xterm or something like that in modes other than 80x25. If your console
supports such a mode, then you can write an application that relies on it
and provides uniform interface locally and over network. In QNX you can’t.
Plus, if one went the route of having consoles
via Photon, you get nice remote access to your main console from Windows.
First, this requires installing Phindows, which is not something everyone is
prepared to do. Then running Photon just to provide pterm is rather
heavy-handed solution. Video drivers are notorious for non-realtime
behavior. And pterm is notorious for eating up CPU on something as simple as
text scrolling. I wonder what if a dozen people start those remote Phindows
sessions…
Perhaps such technical issues are fixable. Then perhaps they should be
fixed… And perhaps QNX can arrange a ready-to-use package/configuration
for using ‘Photon-based-console’. Then maybe someone will take this approach
seriously.
– igor
Igor Kovalenko <kovalenko@attbi.com> wrote:
IK > I really don’t like saying that, but looks like Linux folks keep adding
IK > features while QNX keeps coming up with excuses. You know how that ends,
IK > don’t you 
IK > – igor
Ah, it must be a Monday.
Morning Igor!
Chris,
You are probably right about the scrollbar…it did end up causing my pterm
to extend off the bottom of the screen however. Problem is I’m working on
Linux and one of my co-workers has QNX6 (PE I think). So my time on this
box is somewhat limited.
As for the stripping down, we aren’t really constrained by disk/flash space
restrictions. We run QNX on full-fledged PC’s. This could be our last
resort (using Photon and a stripped down pterm).
Since we do remote support over a modem (ugh!) we were really hoping not to
use Photon and Phindows. Even a plain old console is rough, at times, over
a modem.
You are familiar with how linux handles consoles correct? Essentially with
framebuffer support you can run the console at whatever resolution your
monitor supports. If you’ve ever used linux and framebuffer console you’ll
wonder how you lived without it.
Sounds like everyone has some ideas as to where QNX SHOULD be in this
department. For what we do (automated conveyor applications) QNX’s
real-time capabilities are what keeps us locked in.
Once again I do appreciate everyone’s response. Thanks.
William
Chris McKillop wrote:
William Davis <> bill.davis@fkilogistex.com> > wrote:
Chris,You mentioned there are some tricks to doing this in Photon. Could you
share this information?Prior to my post I played with pterm. I noticed that a pterm would allow
you modify how many rows and columns…but all that seemed to do was add
a scrollbar and cause my pterm to extend off the bottom of the screen.
Scrollbar? Are you sure you are using pterm? It doesn’t support scroll
bars.The only trick is to know how to strip photon down to it’s bare min. size
and to make a pterm-style app that doesn’t have title bars or borders and
always
starts maximized. But the stripping down is only important if you have
disk/flash space restrictions.chris
–
William Davis