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
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: 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
Re: [Fonts] convert font
From: Salvatore Celsomino [EMAIL PROTECTED] there is a system in order to convert a font .bdf or .pcf into font .fon or .ttf. i have tried bdftofon.exe and pcftofon.exe, but for the my font,they have errors: too many characters. thanks ttf2pt1 (http://ttf2pt1.sf.net) can convert .bdf to Type1 (.pfa or .pfb). Conversion to the smooth curves is a bit experimental and incomplete yet, but the direct by-pixel conversion works fine. There is also some interactive editor, I forgot the name, pfaedit or something, that can convert to TTF. -SB ___ Fonts mailing list Fonts@XFree86.Org http://XFree86.Org/mailman/listinfo/fonts
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: 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: 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: 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: 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: 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: 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: [Fonts] help: about how to convert BDF fonts to TTF fonts
zhang hui wrote: Hi, everyone does anyone know any tools which can convert BDF to TTF in linux OS? the tool is important to my current project,so if anyone got the tool,would you please tell me where to download it? please reply me to [EMAIL PROTECTED] as soon as possible thank you very much Ttf2pt1 can do it reasonably decently. http://ttf2pt1.sf.net Look in the Snapshots for the most recent version. -SB ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
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
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
[Fonts]a font server backwards ?
All, I've been thinking about the fonts stuff and I think I've got an interesting idea about the font servers. Normally a font server runs as a TCP/IP server and the X server connects to it as a client. This is not very convenient because it makes running the running of a font server by a random user not very easy. Also if it happens that the font server crashes or has not been started, the X server tends to freese. As far as I understand, the Render extension allows an application to provide bitmaps to be used as fonts. Hovewer these fonts are used only by one application and can't be shared with the others. So a logical next step seems to be an X-client font server. The idea is that the font server connects to the X server as a client, and then does a call indicating that it's a font server. At this point the X server adds this new font server to its font path (I guess, either at the beginning or the end, depending on the options) and uses it as a normal font server, with fonts available to all the X clients. If this connection drops, the X server will silently remove this font server from its font path and go on. This makes such things as starting a personal font server from .profile easy and reliable. Well, the catch is that I don't know enough about the internal workings of the X server and the font protocol to actually implement it (nor really have time) :-( -SB ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[I18n]Re: [Fonts]Another approach to text in X
Alexander Gelfenbain wrote: On Wed, Dec 19, 2001 at 07:20:45PM -0500, Sergey Babkin wrote: Alan Coopersmith wrote: applications. We have designed a display and platform-independent text architecture, the Standard Type Services (ST) framework, which handles not just font rendering, but text layout and font management as well. ST incorporates typographically sophisticated features and ideas from the best regarded existing APIs, including Apple Type Services for Unicode Imaging (ATSUI) and Java2D TextLayouts. On top of ST, we have layered a new extension to the X protocol, called XST, which incorporates the ST functionality. The ST API will also be exposed to applications independant of the X environment so that it can be used It would be good if it also could provide the output in PostScript. It would be capable of generating outlines. Converting them to PostScript is trivial. I think, not quite trivial. I guess I should first explain that I don't want to sound ungrateful, and the way it is now this architecture looks very interesting and useful. Just it seems to me that it's a great opportunity to fix the historical X's weakness with printing. And seeing it missed once again would be a pity. Basically, rendering the general graphics in PostScript is easy and does not require much effort. Rendering of the text is much harder. The major thing making it complicated is the fonts. Of course, transferring the outlines of a rendered page back is a possible thing but it means large size of the resulting file and slow rendering to bitmaps at the printer. Providing a way to convert the used fonts to PostScript fonts, transferring them to the client and then rendering the pages in terms of these fonts looks like a much better thing. And probably provide a protocol to get the kerning information on to the client (unless all the rendering including kerning is done at the server side). Such a conversion is trivial too in the sense that it's clear how it can be done, the only difficulty is to actually do it and to provide an X protocol extension for such a transfer: - the Type1 fonts can be transferred directly, only with the encoding table changed according to X the server's idea about it and with the large fonts split into multiple 8-bit fonts (and/or possibly then combined into a Type0 composite font) - the TrueType fonts can be either converted to Type42 with the algorithm taken from ttf2type42 or converted to Type1 with the algorithm taken from ttf2pt1 - the other fonts can be rasterized to bitmaps and then converted to the Type1 fonts with the algorithm taken from ttf2pt1 Actually, one more possibility is to take the outlines produced from any kind of font and feed them into the algorithm from ttf2pt1. Basically, what I'm trying to say is that since yet another extension is being added to the X protocol, it would be nice to include this font transfer ability into it. -SB ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [Fonts]Another approach to text in X
Alan Coopersmith wrote: applications. We have designed a display and platform-independent text architecture, the Standard Type Services (ST) framework, which handles not just font rendering, but text layout and font management as well. ST incorporates typographically sophisticated features and ideas from the best regarded existing APIs, including Apple Type Services for Unicode Imaging (ATSUI) and Java2D TextLayouts. On top of ST, we have layered a new extension to the X protocol, called XST, which incorporates the ST functionality. The ST API will also be exposed to applications independant of the X environment so that it can be used It would be good if it also could provide the output in PostScript. -SB ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[I18n]Re: [Fonts]Another approach to text in X
Alan Coopersmith wrote: applications. We have designed a display and platform-independent text architecture, the Standard Type Services (ST) framework, which handles not just font rendering, but text layout and font management as well. ST incorporates typographically sophisticated features and ideas from the best regarded existing APIs, including Apple Type Services for Unicode Imaging (ATSUI) and Java2D TextLayouts. On top of ST, we have layered a new extension to the X protocol, called XST, which incorporates the ST functionality. The ST API will also be exposed to applications independant of the X environment so that it can be used It would be good if it also could provide the output in PostScript. -SB ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
