LCDproc development and user support list

Text archives Help


[Lcdproc] Found Reason [not solved]: Was pci-parport segmentation fault


Chronological Thread 
  • From: Nicolas.Saurbier AT biodata.de (Nicolas Saurbier)
  • Subject: [Lcdproc] Found Reason [not solved]: Was pci-parport segmentation fault
  • Date: Wed Jun 30 12:15:02 2004

Hi,

I found out, that 0xe400 is to high for ioperm and iopl is needed...
So, is this fixed in any nightly build/cvs-version ???

If not, can any1 tell me what I have to do to get this working?

BTW: lcd4linux CAN work with 0xe400 ..... ;-)

cheerz

NIC

P.S.: Attached some mailinglist-archive...

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hi,

Joris Robijn wrote:
> I hope this can tell us a bit more why 0xE400 does not work.

oh my god, 0xE400 !, that is high, too high....

from port.h:
/* Get access to a specific port */
static inline int port_access (unsigned short int port) {
return ioperm(port, 1, 255);
}

man ioperm:
Only the first 0x3ff I/O ports can be specified in this
manner. For more ports, the iopl function must be used.

So,
FoulDragon AT aol.com

<mailto:FoulDragon AT aol.com>,
your PCI parallel card=
is no
LCDproc certified Hardware (TM) ;-).


Any volunteers to fix this ?
if port>0x3ff use iopl(3) else use ioperm ?

bye,
Robin Adams
robin AT adams-online.de

<mailto:robin AT adams-online.de>


In a message dated 1/12/2003 5:15:23 PM US Mountain Standard Time,=20
robin AT adams-online.de
writes:

> oh my god, 0xE400 !, that is high, too high....=20

I had no idea... surely plenty of other potential LCDproc users need to use=
=20
PCI parallel-port cards that locate the port somewhere in Nunavut. :)

>Any volunteers to fix this ?
>if port>0x3ff use iopl(3) else use ioperm ?

Your idea seems to work. I did a quick check, changing port_access and=20
port_access_full to ignore the parameters and just be

return iopl(3);

It seems to work fine, in the sense that it displays correctly on my LCD at=
=20
0xe400 now. (FWIW, the display was actually "winamp" protocol, not "8bit". =
I=20
should remember these things from the last time I worked at this.) I don't=
=20
know what, if any, effect it has on a display in a "typical" location (I
assume that's taken care of by the test in your psuedocode), or what nasty
side-effects it has. To me, it sounds like something people won't like fro=
m=20
a security point-of-view. :/

The only thing left that seems odd is that a lot of displays are off-centre=
=2E =20
This is my fault, I believe, since my display is 40x2 instead of the common=
=20
20x4.

--=20
Jack
"You know the display is wired correctly when all the other lights on your
block go dim after you turn the backlighting on."





  • [Lcdproc] Found Reason [not solved]: Was pci-parport segmentation fault, Nicolas Saurbier, 06/30/2004

Archive powered by MHonArc 2.6.18.

Top of page