Hi,
I have some old code that used to work great on older Linux 2.2 kernels
that is now giving me a perror() error message of 'no space left on
device' (ie: ENOSPC) when I call ioctl(GIO_FONT) to save the current
console font.
>From looking at the 2.4 kernel source code that comes with Red Hat 8.0,
it is clear that these functions are implemented on top of a new console
font interface that supports 512 characters and up to 32x32 pixel fonts
(obviously for fb consoles). From my quick look at the code, the ENOSPC
error must be coming because when the new code attempts to save the
console font it must have more than 256 characters or bigger than 8x32
pixels for the font glyphs (which is what the old font interface
supported).
I know I can switch to the new console interfaces (which I will do once I
determine how to do a runtime check for a 2.4 kernel so I can still use
the old code for 2.2 and earlier kernels), but it seems to me that this
bug should be fixed. Is anyone more familiar with the console code able
to provide some feedback on this?
Regards,
---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com
~ SciTech SNAP - The future of device driver technology! ~
"Kendall Bennett" <[email protected]> wrote:
> From looking at the 2.4 kernel source code that comes with Red
> Hat 8.0, it is clear that these functions are implemented on top
> of a new console font interface that supports 512 characters and
> up to 32x32 pixel fonts (obviously for fb consoles).
Yep, after further investigation the problem is that the VGA console is
configured to run with 512 characters, yet the 'old' interface code is
trying to save/restore only 256 characters so it fails. It could be fixed
if it was changed to save/restore 512 characters, but I don't know if
that will break old code (it won't break mine as I always uses a 64K
buffer to save/restore the font tables).
Can someone who is more experienced with the kernel describe how this can
be properly patched?
I have worked around the problem in my code by simply switching to the
new interface (KDFONTOP), but I would like to know what kernel version
this new interface showed up in. If it was in the 2.0 or even 2.2 kernels
that would be fine since that goes back far enough for the support we
need.
Regards,
---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com
~ SciTech SNAP - The future of device driver technology! ~
Followup to: <3E5DE0FC.29370.6FD7FC8B@localhost>
By author: "Kendall Bennett" <[email protected]>
In newsgroup: linux.dev.kernel
>
> "Kendall Bennett" <[email protected]> wrote:
>
> > From looking at the 2.4 kernel source code that comes with Red
> > Hat 8.0, it is clear that these functions are implemented on top
> > of a new console font interface that supports 512 characters and
> > up to 32x32 pixel fonts (obviously for fb consoles).
>
> Yep, after further investigation the problem is that the VGA console is
> configured to run with 512 characters, yet the 'old' interface code is
> trying to save/restore only 256 characters so it fails. It could be fixed
> if it was changed to save/restore 512 characters, but I don't know if
> that will break old code (it won't break mine as I always uses a 64K
> buffer to save/restore the font tables).
>
It will break old code. That's why you've been supposed to use
GIO_FONTX (and GIO_UNISCRNMAP) since the 1.3.1 kernel days (which is
when 512-character support was introduced.)
You're *way* behind the times.
man 4 console_ioctl
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: cris ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64