Is the GIO_FONT ioctl() busted in Linux kernel 2.4?

Is the GIO_FONT ioctl() busted in Linux kernel 2.4?

[Kendall Bennett]

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! ~

Re: Is the GIO_FONT ioctl() busted in Linux kernel 2.4?

[Kendall Bennett]

"Kendall Bennett" <KendallB@scitechsoft.com> 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! ~

Re: Is the GIO_FONT ioctl() busted in Linux kernel 2.4?

[H. Peter Anvin]

Followup to:  <3E5DE0FC.29370.6FD7FC8B@localhost>
By author:    "Kendall Bennett" <KendallB@scitechsoft.com>
In newsgroup: linux.dev.kernel
>
> "Kendall Bennett" <KendallB@scitechsoft.com> 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
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> 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

Is the GIO_FONT ioctl() busted in Linux kernel 2.4?

[Kendall Bennett]

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! ~