Re: Re: patch - word/byte PCI config support for ix86
>From: Marc Aurele La France <[EMAIL PROTECTED]> >On Sun, 9 Apr 2006, Sergey Babkin wrote: > >> I've attached the patch that adds word- and byte-sized >> PCI configuration reads and writes for the ix86 >> platform. The particular reason was to fix the > >> Tha patch was done against the X.org 6.9.0 code. > >This patch is incomplete. There are no ... >- corresponding changes to Pci.h; >- corresponding functions for other platforms. >- calls to these new functions; Oops, I've thought that latest XF86 was synchronized with the Xorg 6.9 code. These other parts are already in 6.9, the ix86 platform was the one lagging behind. The last version of XF86 I've checked was 4.4 from mid-2004 and it does not have ths code indeed, but it's very old too. I guess I can import these changes from 6.9 - probably grab the whole directory, check that there are no other dependencies and drop it in. BTW, there also are changes in the x86emu code between Xorg 6.9 and XF86 4.5, the last release that I've downloaded a few weeks ago. They are somewhat diverging but I think there were more changes in Xorg 6.9 that weren't in XF86 4.5 than the other way around. Would you be interested in merging them in too? >- checks for alignment; I'm not sure what to do about those. There is no way to return an error code, and no use for this error code in x86emu. Besides, for the ix86 platform the access is translated into the real Intel INB/INW instructions which are allowed to have non-aligned addresses, and if the BIOS had some reason to use a non-aligned address, I know no way to do anything better than to pass it through. -SB ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Re: patch - word/byte PCI config support for ix86
>From: Marc Aurele La France <[EMAIL PROTECTED]> >On Sun, 9 Apr 2006, Sergey Babkin wrote: > >> I've attached the patch that adds word- and byte-sized >> PCI configuration reads and writes for the ix86 >> platform. The particular reason was to fix the > >> Tha patch was done against the X.org 6.9.0 code. > >This patch is incomplete. There are no ... >- corresponding changes to Pci.h; >- corresponding functions for other platforms. >- calls to these new functions; Oops, I've thought that latest XF86 was synchronized with the Xorg 6.9 code. These other parts are already in 6.9, the ix86 platform was the one lagging behind. The last version of XF86 I've checked was 4.4 from mid-2004 and it does not have ths code indeed, but it's very old too. I guess I can import these changes from 6.9 - probably grab the whole directory, check that there are no other dependencies and drop it in. BTW, there also are changes in the x86emu code between Xorg 6.9 and XF86 4.5, the last release that I've downloaded a few weeks ago. They are somewhat diverging but I think there were more changes in Xorg 6.9 that weren't in XF86 4.5 than the other way around. Would you be interested in merging them in too? >- checks for alignment; I'm not sure what to do about those. There is no way to return an error code, and no use for this error code in x86emu. Besides, for the ix86 platform the access is translated into the real Intel INB/INW instructions which are allowed to have non-aligned addresses, and if the BIOS had some reason to use a non-aligned address, I know no way to do anything better than to pass it through. -SB ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: patch - word/byte PCI config support for ix86
Sergey Babkin wrote: > > Hi, > > I'm not sure if it's a good idea to cc: to both X.org and > XF86 mailing lists, but the subject is kind of useful > for both. Well, turns out that X.org list doesn't accept e-mail from non-subscribers. So be it, XF86 only then. :-) -SB ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
patch - word/byte PCI config support for ix86
Hi, I'm not sure if it's a good idea to cc: to both X.org and XF86 mailing lists, but the subject is kind of useful for both. I've attached the patch that adds word- and byte-sized PCI configuration reads and writes for the ix86 platform. The particular reason was to fix the support of sincgle-chip Matrox G200 with the VESA driver on UnixWare. This hardware is somewhat brain-damaged and really expects word- and byte-sized bus cycles, it does not work with the wraping in Long. I've added this support only to the type 1 configuration mode, since apparently type 2 hasn't been used in new devices for a few years now. The type 2 should still work in the old-fashioned way, by wrapping around through the Long read/write. It uses the fact that the register 0xCF8 gets written in a Long mode first to selec the bus address. During that write the hardware type detection will be triggered, and if the device uese type 1 configuration, then the pointers to the byte/word access functions would get populated, otherwise for type 2 they would be set to 0 as before. Tha patch was done against the X.org 6.9.0 code. -SB pcifix.df.gz Description: Binary data
Re: Error aboug making XR11
>From: cckuo <[EMAIL PROTECTED]> >Dear All: >There are some error messages I met while making the Xfree86 server. >The message says: >" /bin/sh: line 1: 2926 Segmentation fault" >Does anybody have the same situation before? >Ps: details have been attached. >Thanks a lot!! Either it triggers a bug in your shell, or your shell binary is corrupted, or something is going wrong with the machine (maybe overheating, or some memory SIMM not seated properly, or something is just dying). -SB ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Touch Input Driver port 3.3.6 -> 4.x
Fred Gleason wrote: > > On Wednesday 25 May 2005 08:15, Sergey Babkin wrote: > > The drivers have the defaults compiled into them > > which can be changed from XF86Config. The problem > > is that the ELO driver has (had?) it's defaults > > set to 0-16K as well, so without an explicit > > setting in the config file it does not work > > in any useful manner. > > Sorry for chiming in rather late on this one. Been away for a bit... > > I doubt that setting the defaults for the ELO drivers would make much > difference -- the driver would still be effectively useless until calibrated. >From 2 devices I've worked with (one USB, one serial) both worked fine without any calibration, with factory default ranges. Maybe I've got lucky. -SB ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: RE: RE: Touch Input Driver port 3.3.6 -> 4.x
>From: Veikko Werner <[EMAIL PROTECTED]> >Sergey, > >but anyway if your touchscreen is mounted in the wrong way the pointer will >then not follow your fingertips Yes. But then the picture as displayed by defaut won't be right either :-) ELO sells their touch-screens integrated into the monitors (or at least I haven't seen others) and I guess they mount it close enough from the factory. >this is from xf86Elo.c >< >#define DEFAULT_MAX_X 3000 >#define DEFAULT_MIN_X 600 >#define DEFAULT_MAX_Y 3000 >#define DEFAULT_MIN_Y 600 >> Ah, I guess either I've remembered wrong or it got changed during the last year or so. Those values are still not right though. The ELO people are actually very nice, they can be reached on the phone and promptly send the PDF with the programming guide to their devices. I think they didn't even require an NDA. I've got one for the USB devices which return the correct limits in their USB device descriptor. But an experiment has shown that the serial devices use the same values. -SB ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: RE: Touch Input Driver port 3.3.6 -> 4.x
>From: Veikko Werner <[EMAIL PROTECTED]> > >There are no default Xmin/Max Ymin/Max values for any resistive touch devices. >A good possibility would be to include a calibration routine into the driver >if possible. There are manufacturer-specified ranges for both ELO and Microtouch (though I don't know if they are using the resistive technology). They may be not perfectly precise but they are good enough for the precision of a finger touch - since the fingers are much bigger than pixels, you can't touch a particular pixel anyway. For ELO the range is around from 300 to 3700 I don't remember the exact numbers, for Microtouch it's from 0 to 16K. The drivers have the defaults compiled into them which can be changed from XF86Config. The problem is that the ELO driver has (had?) it's defaults set to 0-16K as well, so without an explicit setting in the config file it does not work in any useful manner. -SB >> -Original Message- >> From: Sergey Babkin [mailto:[EMAIL PROTECTED] >> Sent: Saturday, May 21, 2005 2:52 AM >> To: devel@XFree86.Org >> Subject: Re: Touch Input Driver port 3.3.6 -> 4.x >> >> >> Fred Gleason wrote: >> > >> > On Wednesday 18 May 2005 18:48, Quentin Olson wrote: >> > > I have the source for an old input driver that was >> written for XFree86 >> > > 3.3.6 that I would like to use under 4.x (4.5). Is there any >> > > documentation on what is required, howtos, etc.? >> > >> > Which touch hardware in particular are you trying to >> support? A driver for >> > the USB-based ELOs was just recently added. >> >> BTW, the serial ELO driver could benefit by setting the defaults >> X and Y ranges correctly. They are something like 300 to 3700, >> same as for USB. I can look up the exact values in the ELO docs >> if anybody cares. >> >> Or maybe they are already correct now - I haven't checked it >> for a while. >> >> -SB >> ___ >> Devel mailing list >> Devel@XFree86.Org >> http://XFree86.Org/mailman/listinfo/devel >> ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: magictouch touch screen driver
[EMAIL PROTECTED] wrote: > > Hi everybody, > > I am interested in getting the magictouch driver running. According to the > cvs comments, it needs updating to the new 4.x interfaces. My questions > are then: > > - If there is no good sample driver, which driver would be a good starting > point ? i.e. up to date, not cluttered by extra device-specific stuff... I think the ELO one is simple enough. -SB ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Touch Input Driver port 3.3.6 -> 4.x
Fred Gleason wrote: > > On Wednesday 18 May 2005 18:48, Quentin Olson wrote: > > I have the source for an old input driver that was written for XFree86 > > 3.3.6 that I would like to use under 4.x (4.5). Is there any > > documentation on what is required, howtos, etc.? > > Which touch hardware in particular are you trying to support? A driver for > the USB-based ELOs was just recently added. BTW, the serial ELO driver could benefit by setting the defaults X and Y ranges correctly. They are something like 300 to 3700, same as for USB. I can look up the exact values in the ELO docs if anybody cares. Or maybe they are already correct now - I haven't checked it for a while. -SB ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 4.4.0 RC3
Juliusz Chroboczek wrote: > > DD> [XFree86] was not, as a whole, FSF-free before the change, let > DD> alone GPL-compatible. Same after the change. But then XFree86 > DD> has never factored in those two licensing criteria. > > That's not quite the point, David. > > Of the many reasons for which I was happy to contribute my work to > XFree86 was that the old licence guaranteed that anyone could use my > code. It was okay for Debian or FreeBSD to grab a routine that I > wrote, as it was for Apple or Microsoft. I believe it still is. > Unless I've missed a post, you still haven't explained what it is that > you're trying to achieve with the new licence. I would like to hear > you justify that the advantages of the new licence justify what I > perceive as a net loss in code availability. My understanding is that they've essentially made it a copy of the classic BSD license. So I don't see anyhting to worry about. It's interesting that FreeBSD is actually moving in the opposite direction: many of the newer contributions have the clause "do not use our names in advertisement" removed. -SB ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: does XFree86 need kernel framebuffer support?
Tim Roberts wrote: > > Andrew C Aitchison wrote: > > >XFree86 does not in general need kernel framebuffer support for > >hardware which is supported by an XFree86 driver, as it has its own > >framebuffer interface. > > > >There are two cases where XFree86 does need kernel support. > >* Chipsets like the i810/i815/i835/... family have no framebuffer memory > >but use main system memory for the framebuffer. This requires agpgart > >support from the kernel. > > This doesn't actually REQUIRE agpgart support from the kernel unless > you're doing bus mastering. The ProSavages are UMA chips, with their > frame buffers in main memory, and as long as the BIOS has done the > proper division of memory at boot time, that's all it needs. Many of the cards in the i810 family have only a very limited amount of video memory on the card. So if you want to get anything over 800x600 on them, you need agpgart. On some of them the i810 driver won't start even in 800x600 mode, so VESA is the only option. -SB ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Manufacturers who fully disclosed specifications for agp cards?
"Mike A. Harris" wrote: > > On Tue, 3 Feb 2004, Knut J Bjuland wrote: > > >Date: Tue, 03 Feb 2004 15:52:53 +0100 > >From: Knut J Bjuland <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Reply-To: [EMAIL PROTECTED] > >Content-Type: text/plain; charset=us-ascii; format=flowed > >Subject: Re: Manufacturers who fully disclosed specifications for agp > >cards? > > > >It is possible to gain the specs for a chip by discetion for i.e R300 > >chip or NV 30 chips with the right tools like a electon microscope? > > Not unless you're using the electron microscope somehow to break > into ATI or Nvidia headquarters, perhaps swinging it from a crane > to break a window or something. Well, a more realistic way would be to disassemble their Windows drivers. Or if they have a binary-only Linux driver, that one would be simpler than the Windows one. Of course that may be violating DMCA and they may send a mob of lawyers after you. On the other hand, the copyright laws in Europe are different, so maybe it's OK to do there. I know for sure that the Russian copyright law expressly allows disassembling the codes for the purpose of learning the programmatic interfaces. I've heard different opinions about what DMCA thinks about it in US. -SB ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: patch for a crash in x86 emulator
David Dawes wrote: >>return not NULL pointer but a valid pointer to some trash value, >>so that their caller would be able to reference it without crashing >>before the interpreter has a chance to halt. > >Yes, that is a problem. The INTR_HALTED flag isn't tested until too >late. The potential problem of returning a trash value is that could >cause bad things too. Maybe the callers of functions that can return >NULL need to check for that, and abort the instruction? Then >INTR_HALTED >will be noticed before moving on to the next instruction. Maybe a better way would be to check in the callers for INTR_HALTED and return immediately. This should handle nested calls relatively easily, with the same thing done in each function. Otherwise if there are nested calls the inner funtions will need to devise some special values to indicate the abort to their callers too. Thanks for the printk() pointer! -SB ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: patch for a crash in x86 emulator
> when crashed was 0x0100. BTW, the emulator supports FS/GS throughout > most of it, just it was missing in the R/M decoding. Oh, and the call made was setting the video mode. It crashed in a very unpleasant way too, leaving the screen in a dead state. I have more details written down at work, if you are interested. -SB ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: patch for a crash in x86 emulator
Oops, somehow I've thought that I was subscribed to the list but it iurns that I was not - I guess I've stopped it before vacation and forgot to turn back on. So sorry about the delay. >>I've been running XFree86 4.3.0.1 on a machine with a particularly >>weird videocard and I've got the VESA driver craching. >>... >>A little investigation has shown that it crashes in >>x86emuOp_mov_word_SR_RM() >>... >>This happens because destreg is 0, because it's returned that way >>from decode_rm_seg_register(). rh is 4, and that's the value that >>decode_rm_seg_register() in decode.c (also linked from extras) does >>not understand. I've looked it up in the manual and actually >>the value 4 is for FS and value 5 is for GS. > >So, the conclusion here is that the Intel 815 BIOS uses FS and GS? That >is both surprising and disturbing. Maybe it's only some particular version. Because of 5 types of machines I have with o810-i815-i845 this is the only one that caused a crash. >The BIOS runs in real/v86 mode, and is not generally allowed to make any >assumptions about the addressing in the machine. XFree86 doesn't map in >any low-memory sections other than the segments at 0, A, B, >and C. Given that, it is hard to imagine a scenario where DS and ES >are not completely sufficient to do the job. Well, with 4 potential segments using 4 segment registers makes sense. If it's of any interest, the value that it tried to load into FS when crashed was 0x0100. BTW, the emulator supports FS/GS throughout most of it, just it was missing in the R/M decoding. -SB ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
patch for a crash in x86 emulator
Hi,
I've been running XFree86 4.3.0.1 on a machine with a particularly
weird videocard and I've got the VESA driver craching. If anyone
wonders, the BIOS data in the log is:
(II) VESA(0): VESA BIOS detected
(II) VESA(0): VESA VBE Version 3.0
(II) VESA(0): VESA VBE Total Mem: 1024 kB
(II) VESA(0): VESA VBE OEM: Intel(R) 810, Intel(R) 815 Chipset Video BIOS
(II) VESA(0): VESA VBE OEM Software Rev: 37.16
(II) VESA(0): VESA VBE OEM Vendor: Intel Corporation
(II) VESA(0): VESA VBE OEM Product: Intel(R) 810, Intel(R) 815 Chipset
(II) VESA(0): VESA VBE OEM Product Rev: Hardware Version 0.0
The machine is a retail box with embedded LCD touch-screen.
A little investigation has shown that it crashes in
x86emuOp_mov_word_SR_RM() (in programs/Xserver/hw/xfree86/int10/ops.c
which is symlinked from extras/x86emu/src/x86emu) on the underlined line:
case 3: /* register to register */
destreg = decode_rm_seg_register(rh);
DECODE_PRINTF(",");
srcreg = DECODE_RM_WORD_REGISTER(rl);
DECODE_PRINTF("\n");
TRACE_AND_STEP();
*destreg = *srcreg;
^^
break;
This happens because destreg is 0, because it's returned that way
from decode_rm_seg_register(). rh is 4, and that's the value that
decode_rm_seg_register() in decode.c (also linked from extras) does
not understand. I've looked it up in the manual and actually
the value 4 is for FS and value 5 is for GS. So here is the
patch (also attached, to avoid corruption by the mailer):
-- cut here ---
*** decode.c.0 Thu Dec 4 15:42:51 2003
--- decode.cThu Dec 4 17:15:29 2003
***
*** 699,705
--- 699,709
DECODE_PRINTF("DS");
return &M.x86.R_DS;
case 4:
+ DECODE_PRINTF("FS");
+ return &M.x86.R_FS;
case 5:
+ DECODE_PRINTF("GS");
+ return &M.x86.R_GS;
case 6:
case 7:
DECODE_PRINTF("ILLEGAL SEGREG");
-- cut here ---
This patch made the X server to work with this card.
Could someone please check it in? I've looked in CVS and the most
recent version still has this bug in it.
There is also a more general question: in case when an instruction opcode
can't be decoded, many routines in decode.c rely on just calling
HALT_SYS() for error handling. However HALT_SYS() expands to
X86EMU_halt_sys() which does nothing but sets a flag. The decode
routines return 0 instead of all kinds of pointers to their caller
which would immediately try to reference that pointer and crash.
That means that any misformatted routine met in BIOS will make the
X server to crash. I think that it's not good. I think that in case
of a bad opcode an error message has to be printed into the log,
so that the user would have some clue, and then the decoders must
return not NULL pointer but a valid pointer to some trash value,
so that their caller would be able to reference it without crashing
before the interpreter has a chance to halt.
If I make a patch to fix it as described, would anyone be willing to
review and commit it? (BTW, any pointers to how to print an error
message properly from the bowels of the i86 interpreters would be
appreciated too).
-SB
decode.df.gz
Description: GNU Zip compressed data
