Re: DPI with multiple heads and virtual desktops
On Sun, Aug 24, 2003 at 11:16:23PM +0200, Alexander Pohoyda wrote: David Dawes [EMAIL PROTECTED] writes: Xinerama *hides* the fact that there are two heads, so there is no way for the app to be told a different DPI debending which head it is currently on - what should it be told if it is on both ? This is my point exactly. When I raised this issue it was not to elicit a correct solution, but rather to point out that the whole notion of DPI is nonsense WRT Xinerama/MergedFB. I would suggest this as a correct-ish solution: If Xinerama/MergedFB detects that both screens have nearly the same resolution (to within some configurable tolerance) then use the average of the two. Otherwise the user has to specify the DPI to use with the -dpi command line switch or some other mechanism. (Is there a DPI option in the XF86Config file?) It might be nice to be able to specify use DPI from screen foo in the ServerLayout section to simplify the process a bit. There is no DPI option in the XF86Config file, but one could be added. That's true, but we have DisplaySize property in the Monitor section. The -dpi command line option is global, applying to all screens. I see. Is it updated in the Xserver manual page? I have the old version which goes like this: -dpi resolution sets the resolution of the screen, in dots per inch. To be used when the server cannot determine the screen size from the hardware. I don't see how that description is inconsistent with what I said. Maybe knowing how it works influences the way I read the description? David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: patch to include some kernel info in banner
On Tue, 12 Aug 2003, Daniel Stone wrote: This patch puts the kernel version in the banner, on Linux, and also whether or not it's tainted (providing it's a sufficiently recent kernel). Thanks to Mike Harris for this patch (slightly altered to remove RH_CUSTOM, etc). Please do not accept this Linux-specific hack of a patch; I merged it to Debian, and Mike asked me not to send it upstream. Granted, as the patch stands. However, I don't mind doing the minimal fixing up for inclusion, as this information would be extremely useful in some logs. Feel free to make it more generic and include it - that would definitely be cool. Why the extra symbol, if I may ask, instead merely using defined(linux)? I don't know, I just grabbed it off Mike and did s/RH_CUSTOM/KERNEL_VERSION_IN_BANNER/; I think RH_CUSTOM is a catch-all for Red Hat's whacky stuff. Yes, I wrote the patch to more or less do what I wanted it to do, but in as little time as possible. It works, however it is far from clean code. Just a very very ugly quick hack, not suitable for inclusion. I used RH_CUSTOM to indicate that it is just an ugly custom hack, as I know nobody would include code upstream with such slop in it. My intention, was to some time down the road, rewrite it in an OS and distribution neutral manner, and clean up the ugliness, then offer it for potential inclusion. I figured I'd finish off a number of other hacks first and include them in one fell swoop, once they were in clean enough shape to send upstream. In general, if you see me use RH_CUSTOM, or something else that is obvious wouldn't get accepted upstream, I've done it to indicate that the patch is just a temporary kludge/fix/hack or similar depending on what it's doing. It's intended to be an indicator to others to feel free to use/modify the bits if they like, but to not submit it upstream as-is. The novelty of the quick hack was too great to leave it out until I had time for a proper generic solution. Seeing that information in bug reports has been a tremendous God send, in particular the kernel version running, buildhost, and tainting flags. Of course you're free to tidy it up as you have, and use it as well. I see something has been commited to CVS based on my original, so I'm glad to see someone liked the idea enough to do the dirty work I never got around to doing quite yet. I've got some other patches in current rpms which change the server error messages to be more modern and contain more info. The messages are currently Red Hat centric though - again, to get what I needed done ASAP, with intention to genericize and submit upstream. Basically I've changed the messages to point to bugzilla to report bugs, and a few other similar things. ftp://people.redhat.com/mharris/testing/unstable/XFree86/4.3.0-22/sources/XFree86-4.3.0-redhat-bug-report-address-update.patch That patch in our current rpms, is distro specific, but what I'd like to do before submitting it upstream, is modify it so that the X server default build, has an XFree86 specific message for the project itself, but permits distribution specific overrides to allow various OS distros to override the bug report address and mechanism to find updates. For example, a Red Hat user would want to know both how to report a bug to Red Hat via bugzilla, and to XFree86.org via bugzilla, and they'd want to get updates via our up2date tool if possible, or via ftp from our ftpsite, or alternatively from XFree86.org site's binaries or source tarballs. Assuming the idea is considered sane and acceptable, the exact text of the XFree86.org generic strings I can write up something I think might work best for the project itself, and then submit the patch which allows distro overrides to that text to bugzilla, and David or someone can review and modify to taste and commit it if they deem it a sensible addition. It's a trivial amount of work to do, so I can probably whip out something in short order if deemed to be something useful generically in XFree86. Any feedback appreciated. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: patch to include some kernel info in banner
On Sun, 24 Aug 2003, Marc Aurele La France wrote: This patch puts the kernel version in the banner, on Linux, and also whether or not it's tainted (providing it's a sufficiently recent kernel). Thanks to Mike Harris for this patch (slightly altered to remove RH_CUSTOM, etc). Please do not accept this Linux-specific hack of a patch; I merged it to Debian, and Mike asked me not to send it upstream. Granted, as the patch stands. However, I don't mind doing the minimal fixing up for inclusion, as this information would be extremely useful in some logs. Feel free to make it more generic and include it - that would definitely be cool. Done. I opted to use uname(2) instead. This doesn't say anything about Linux's tainted thingie, but Mike can send a patch to include it if he, or anyone else, feels that strongly about it. Yeah, my original patch used uname(), but one of the critical pieces of information I wanted in the output was the kernel tainting flags, so I know if someone is running X under a tainted kernel or not. Also, uname output lacked some of the additional useful things the /proc/version file contains which are helpful in troubleshooting. I switched from uname to /proc/version to get the extra kernel build info and whatnot. Both of these things however are very non-generic and the code looks like crap... but it worked well. ;o) I wasn't sure what would be best to submit upstream other than using uname() as you've done, and possibly having conditionalized Linux specific code. That's still a bit ugly though. Once I update my rpms to the latest codebase, I'll see if I can brainstorm some way of getting the best of both worlds without it looking like a horrible mess. If not, it's best keeping the horrible mess as a vendor addition. Just as an additional note, I've tried to keep the convention of using Red Hat specific patches not intended to be submitted upstream in the form XFree86-a.b.c-redhat-foo.patch I made comments in our spec file to explain this, so people are clearer that these patches are not intended for upstream, but they're of course useable/modifyable/etc. to anyone who thinks they're useful, including the XFree86 project. Just trying to keep the ugly stuff buried. ;o) Thanks Marc. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: patch for ia64 page size
On Sun, 10 Aug 2003, Warren Turkal wrote: Date: Sun, 10 Aug 2003 19:06:58 -0500 From: Warren Turkal [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Subject: patch for ia64 page size Here is a patch for page size problems on ia64 and radeon. Patch by Chris Ahna: Fixes critical page size problems on ia64 architecture. See following URL for details: https://external-lists.valinux.com/archives/linux-ia64/2001-August/002037.html Comment by [EMAIL PROTECTED]: Why are you submitting _my_ patch, without even asking me about it? If you had, I'd have told you that that patch is an ugly mess, not suitable for upstream submission for numerous reasons. It works, but it is far from clean and ready for inclusion in CVS. Before submitting my patches upstream, please contact me first to find out what my own plans are. I generally send patches upstream myself personally when I feel they are ready to be included upstream. If I haven't, it is a good idea to ask me why not first. I can save you some headaches. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: patch for ia64 page size
On Mon, 11 Aug 2003, Alex Deucher wrote: Date: Mon, 11 Aug 2003 06:25:21 -0700 (PDT) From: Alex Deucher [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Subject: Re: patch for ia64 page size You might want to create a bug in bugzilla (bugs.xfree86.org) and attach the patches there. that way people can comment on the patches and the committers usually post a comment there if they decide to include it. No, please don't. Those pagesize patches are ugly hacks currently, and are not suitable for XFree86.org. Don't waste their time please. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: patch for ia64 page size
Mike A. Harris wrote: On Sun, 10 Aug 2003, Warren Turkal wrote: Date: Sun, 10 Aug 2003 19:06:58 -0500 From: Warren Turkal [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Subject: patch for ia64 page size Here is a patch for page size problems on ia64 and radeon. Patch by Chris Ahna: Fixes critical page size problems on ia64 architecture. See following URL for details: https://external-lists.valinux.com/archives/linux-ia64/2001-August/002037.html Comment by [EMAIL PROTECTED]: Why are you submitting _my_ patch, without even asking me about it? If you had, I'd have told you that that patch is an ugly mess, not suitable for upstream submission for numerous reasons. It works, but it is far from clean and ready for inclusion in CVS. Before submitting my patches upstream, please contact me first to find out what my own plans are. I generally send patches upstream myself personally when I feel they are ready to be included upstream. If I haven't, it is a good idea to ask me why not first. I can save you some headaches. These patches are included in the debian packages for X. I was trying to make sure that the stuff got included in X so that other distributions could take advantage of it. I simply tried to make it apply and then sent it to the list in hopes that more knowledgable developers would let me know its status or include it if they chose. I was just trying to help. Warren Turkal -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: DPI with multiple heads and virtual desktops
On Mon, Aug 25, 2003 at 07:40:40PM +0200, Alexander Pohoyda wrote: David Dawes [EMAIL PROTECTED] writes: Xinerama *hides* the fact that there are two heads, so there is no way for the app to be told a different DPI debending which head it is currently on - what should it be told if it is on both ? This is my point exactly. When I raised this issue it was not to elicit a correct solution, but rather to point out that the whole notion of DPI is nonsense WRT Xinerama/MergedFB. I would suggest this as a correct-ish solution: If Xinerama/MergedFB detects that both screens have nearly the same resolution (to within some configurable tolerance) then use the average of the two. Otherwise the user has to specify the DPI to use with the -dpi command line switch or some other mechanism. (Is there a DPI option in the XF86Config file?) It might be nice to be able to specify use DPI from screen foo in the ServerLayout section to simplify the process a bit. There is no DPI option in the XF86Config file, but one could be added. That's true, but we have DisplaySize property in the Monitor section. The -dpi command line option is global, applying to all screens. I see. Is it updated in the Xserver manual page? I have the old version which goes like this: -dpi resolution sets the resolution of the screen, in dots per inch. To be used when the server cannot determine the screen size from the hardware. I don't see how that description is inconsistent with what I said. Maybe knowing how it works influences the way I read the description? Sorry, I didn't imply the inconsistency in your words. I only think that current description could benefit from some more details. In my eyes, it would be worth mentioning that this option will apply to all screens. OK. Also, I believe that it would be good to state that the -dpi option will overwrite the resolution of all screens even in the case when resolution is implicitely defined via Monitor/DisplaySize and Screen/Display/Modes options. If it's the case. I guess we should state somewhere that command line options always override parameters from elsewhere, just as parameters supplied explicitly in the config file override auto-detected values, which in turn override fall-back default values. I'll try to make this clearer in the relevant man pages. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: *** xf86BiosREAD, IA64, Multi-card Init ***
I have spent quite a bit of time investigating this issue and I think we now understand the underlying issue. The various places in XFree86 that mmap memory seem to very careful to specify the proper mapping attributes, e.g. when mapping registers with ordering requirements and side-effects (e.g. MMIO) the mapping is forced to be non-cached and ordered. But ROM (e.g. device bios) can be read cached, it has no side-effects. Thus when xf86ReadBIOS maps the ROM BIOS it does not force a non-cached mapping. In theory this is correct. However on IA64 the concept of caching is overloaded, not only does it refer to memory coherence but more importantly selects between two vastly different memory spaces, RAM and IO. A cached access is directed to RAM and a non-cached access is directed to IO (e.g. a pci device). It was observed that ROM reads using the standard VGA ROM base of 0xC were successful, but ROM reads using a base address computed from the PCI TAG (e.g. using the ROM BAR) failed unless the caching attribute was asserted. Note that at boot time the VGA bios is copied from the card to RAM at 0xC (e.g. the shadow copy) as is required by the PCI spec. In XFree86 it uses the symbol V_BIOS for this address. This implies the following: 1) Reading the bios at 0xC must be cached so that it is directed to RAM. 2) Reading a bios on the card must be non-cached so that it becomes an IO access. This means if there is a common routine (e.g. xf86ReadBIOS) it must distinguish between whether the base address is a shadow copy or not. This also explains why cached reads of 0xC were successful and why cached reads off the card failed (and in most cases should have machine checked). If our analysis is correct it means we can't just force a non-cached mapping unless we know if we are pointing to a shadow or the physical IO address of the bios. This problem only seems to show up when there is a second graphics card in the system. This also makes sense to me. The primary card has its VGA shadowed at 0xC in RAM. But if a driver or int10 code want to read the bios on the non-primary card it can't use the VGA ROM base because that belongs to the primary, it must get it from the PCI config and read it from the card. I went looking for the place in the XFree86 code that reads rom bios using the tag, as this seems to be a key element, but I didn't find it yet. Can someone point me at it? On the assumption this analysis is correct should we ifdef xf86ReadBIOS for __ia64__ and test for anything in the range of 0xC to 0xC+size and modify the mapping based on that test? Are there any places in the server which read BIOS that is not done via the utility xf86ReadBIOS? John ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: cvs:drivers/via/via_driver.c: problem with Virtual
Committed. death writes: Seperate modelines error out on: width too large for virtual size for everything since this virtual width then is 0. Virtual config does not work, max/default usable size is used instead. Reason: via_driver.c:VIAPreInit: xf86ValidateModes is called with pScrn-virtual[XY] instead of pScrn-display-virtual[XY] This looks like a plain oversight from via which has existed since 1.1. and is pretty trivial. Thanks, Luc Verhaegen --- xc/programs/Xserver/hw/xfree86/drivers/via/via_driver.c 2003-08-25 04:05:39.0 +0200 +++ xc1/programs/Xserver/hw/xfree86/drivers/via/via_driver.c 2003-08-25 04:05:39.0 +0200 @@ -1504,8 +1504,8 @@ 16 * pScrn-bitsPerPixel, /* pitch inc (bits) */ 128, /* min height */ 2048, /* max height */ - pScrn-virtualX, /* virtual width */ - pScrn-virtualY, /* virutal height */ + pScrn-display-virtualX, /* virtual width */ + pScrn-display-virtualY, /* virtual height */ pVia-videoRambytes, /* size of video memory */ LOOKUP_BEST_REFRESH); /* lookup mode flags */ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: *** xf86BiosREAD, IA64, Multi-card Init ***
On Mon, 2003-08-25 at 14:51, David Dawes wrote: However on IA64 the concept of caching is overloaded, not only does it refer to memory coherence but more importantly selects between two vastly different memory spaces, RAM and IO. A cached access is directed to RAM and a non-cached access is directed to IO (e.g. a pci device). Does this mean that the video memory aperture on a PCI device is classified as RAM, or is there something else that ensures that cached accesses get directed to the PCI device in this case? Is the difference that this is a writeable region while the ROM is read-only? I just received information from HP (thank you Bjorn Helgaas) that the memory attribute does not direct access between RAM and IO, I was in error. But what is critical is that the EFI MDT (Memory Descriptor Table?) which is set up at boot time is the arbiter of which memory attributes are used for various memory regions. User space mappings that try to force cached vs. non-cached accesses are inappropriate, its not their decision, rather it must be consistent with the EFI table which is set up at boot time. There is a kernel patch that ignores the user request for cached vs. uncached mappings and instead (indirectly) consults the EFI MDT such that the memory attribute field in the TLB is consistent with how that memory is referenced in the system, as determined by the firmware (EFI). Beta RH kernel's were missing this patch that had been present in earlier kernels. Bjorn tells me that with the patch applied no changes need to be made to X for proper operation and that the patch is in the upstream kernel sources. FYI, the patch follows for those interested, note that O_SYNC is no longer used as a trigger for non-cached access. --- drivers/char/mem.c 2003-08-21 15:55:17.0 -0600 +++ /home/helgaas/linux/testing/drivers/char/mem.c 2003-08-13 10:54:25.0 -0600 @@ -180,6 +177,11 @@ test_bit(X86_FEATURE_CYRIX_ARR, boot_cpu_data.x86_capability) || test_bit(X86_FEATURE_CENTAUR_MCR, boot_cpu_data.x86_capability) ) addr = __pa(high_memory); +#elif defined(__ia64__) + struct page *page; + + page = virt_to_page(__va(addr)); + return !VALID_PAGE(page) || PageReserved(page); #else return addr = __pa(high_memory); #endif @@ -194,7 +196,11 @@ * through a file pointer that was marked O_SYNC will be * done non-cached. */ +#ifdef __ia64__ + if (noncached_address(offset)) +#else if (noncached_address(offset) || (file-f_flags O_SYNC)) +#endif vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot); /* Don't try to swap out physical pages.. */ -- John Dennis [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Static server build problems in via driver
Egbert Eich writes: David Dawes writes: Is the static build problem likely to be fixed before Monday's snapshot? I doubt it. I'm quite overloaded with work. I was going to merge in the latest patch however I had conflicts applying it. I need to investigate some more. Maybe I get to it later today. OK. I've committed the latest patches and fixed the static build. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: about XFree 4.x driver ATI 3D Rage LT Pro
there is support for 3D on mach64 in the DRI CVS tree. see here for more details: http://www.retinalburn.net/linux/dri_status.html binary snapshots are available here: http://dri.sourceforge.net/snapshots/bleeding-edge/ Alex --- mark dohl [EMAIL PROTECTED] wrote: hi, at the same time I read there or there that this video chip is or not 3D accelerated under Xfree 4.x could someone who knows answer me by yes or no? thx md __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: about XFree 4.x driver ATI 3D Rage LT Pro
ok, it's not yet included within XFree. I was dubting, because when I read http://xfree.org/4.3.0/Status6.html#6 I believed it was already included but was not able to make it working. so, end of the thread. thx md --- Alex Deucher [EMAIL PROTECTED] wrote: there is support for 3D on mach64 in the DRI CVS tree. see here for more details: http://www.retinalburn.net/linux/dri_status.html binary snapshots are available here: http://dri.sourceforge.net/snapshots/bleeding-edge/ Alex --- mark dohl [EMAIL PROTECTED] wrote: hi, at the same time I read there or there that this video chip is or not 3D accelerated under Xfree 4.x could someone who knows answer me by yes or no? thx md __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
