Hi.
Mariano, I think that you should change the comment to USE_INOUTP_FRAMEDRIVERS to read that a 'n' must be used with svgalib-1.9.x. First, these don't work by default because GRX does nothing to gain port access, it simply derives that priviledge from svgalib 1.4.3 (and not from 1.9.x); thus, even a suid root svgalib-1.9.x GRX executable still fails with a coredump at the first in/outport instruction. Second, even if an ioperm(2) is established, the drivers still don't work well - looks like a port conflict between svgalib or svgalib kernel module and GRX to me. I can't remember if the drivers ever worked with 1.9.x, my previous tests were about 6 months ago... Anyone else willing to check that?
Dimitar Zhekov wrote:
Hi.
Mariano, I think that you should change the comment to USE_INOUTP_FRAMEDRIVERS to read that a 'n' must be used with svgalib-1.9.x. First, these don't work by default because GRX does nothing to gain port access, it simply derives that priviledge from svgalib 1.4.3 (and not from 1.9.x); thus, even a suid root svgalib-1.9.x GRX executable still fails with a coredump at the first in/outport instruction. Second, even if an ioperm(2) is established, the drivers still don't work well - looks like a port conflict between svgalib or svgalib kernel module and GRX to me. I can't remember if the drivers ever worked with 1.9.x, my previous tests were about 6 months ago... Anyone else willing to check that?
In fact, I'm thinking to set 'n' like the default, because even with svgalib 1.4.x the 4bpp driver fails if you set linux start with the framebuffer enabled (I don't know why).
-
Dimitar Zhekov -
Mariano Alvarez Fernandez