Re: XFree86 4.4.0 RC3
On Wed, 18 Feb 2004, David Dawes wrote: >The big deal you are all making about the GPL-incompatibility of >the modified XFree86 licence is really quite minor in comparison. >Lets face it: Your real objection is to giving credit to XFree86 >and its contributors. GPL-incompatibility and FUD about FSF-freeness(*) >of the modified licence is just a poor excuse. You're very wrong there David. I believe that the XFree86 project very much deserves credit for any work that the project does do. I have every intention, when using XFree86 project written code, or supplied patches, etc. of giving the project full credit for anything that it has done regardless of whatever license is used. The credit is given not because of some license or legal requirement, but because it is just the proper and moral thing to do. If there is any code from XFree86 which I personally have used and did not give proper attribution for in the past, I definitely want to know about it, so that I can correct the problem. I am a strong believer in giving proper credit where it is due, however I also realize that human err can cause mistakes to happen sometimes. It is in everyone's best interest to work together in pointing out such cases of human error in a friendly way, so that everyone involved has proper credit given to them. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: i855GM: New BIOS breaks i810-driver
Christian Zietz writes: > Hi, > > as developer of 855patch I get a lot of feedback from people using > XFree86 on computers with i855GM graphics. > It seems like new notebooks by Dell feature a new video BIOS from Intel > (iirc Build 3066) which finally implements the int 0x10 0x5f11 function > to set the amount of video RAM and thus making 855patch obsolete. > > But the i810-driver refuses to work on systems with that BIOS version. I > had several independent reports of users who just get a completely green > screen when starting XFree86. I had a look on a log file and found > nothing unusual. The XFree86 VESA driver however works but just in low > resolutions/color depths as there is no way to allocate more video RAM > there. > > As I've been absent of this list: Is this already a known issue? > I haven't heared anyting about this issue yet. The first question that comes to my mind is: What happens if a low resolution mode that works with VESA is set on the i8xx driver? Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Modifications to linuxPci.c to optimize PCI scan
On Tue, 17 Feb 2004, Tim Roberts wrote: > Pier Paolo Glave wrote: > >I'm trying to optimize an embedded system based on > >ARM9 CPU, which is running a cross-compiled version of > >XFree86 4.3.0 on linux 2.4.18. > >I noticed that XFree86, at start-up, makes a complete > >scan of 256 possible PCI buses, looking for devices, > >without checking (e.g. from /proc/bus/pci) how many > >buses are actually present on the system. > >I thought that in my system, where I have one bus > >only, this could lead to a high startup time, so I > >tried to make a patch (reported below) that detects > >the actual number of buses by parsing > >/proc/bus/pci/devices. > >The results were not amazing, because the saved time > >is really little. > Right. The gain is very, very small, and it comes at the cost of an > additional dependency on the presence and exact format of > /proc/bus/pci/devices. /proc/bus was not introduced until the 2.2 > kernels, so your change would prevent XFree86 from running on 2.0.x > kernels. I don't know whether there are other issue with 2.0.x kernels > or not, but since the cost of a full PCI bus search is so small, it > seems counterproductive to make this change. This comment is incorrect given that the code Pier modifies isn't even traversed with a 2.0 (or earlier) kernel. However, I'd defer this change to a post-4.4 timeframe because it's not a bug fix. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: trivial patch for startx.cpp
On Sat, 14 Feb 2004, Tyler Retzlaff wrote: > > If you read the notice that accompanied the change you are refering to, > > you will see that this change of yours is unnecessary. > I'm not sure why you feel it's unnecessary since I never declared my > motivation for the change. I use tools (external to the xfree > project) to process these cpp scripts. > I admit, until recently I only used them on xf4.3 and earlier but this > one script stands out from the others because of the XCOMM not > starting at col 0. I only made the change request because it doesn't > seem consistent with the rest of the scripts in the tree. Yes, but the '#'-signs the XCOMM's eventually turn into are still preceeded by whitespace, just like they were intended to be in the startx script generated prior to this change. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Crashing Xvfb
Jeff, Thanks for the info (its good to know I'm not alone) and at least I now have a backup plan if Xvfb cannot be fixed easily. If I get stuck trying to configure vncserver, could I contact you directly? That said, it would be better if Xvfb worked without crashing. Who looks after the vfb code these days? It would be nice to know if there's anything I could do to help with fixing this bug. Also, should I enter a bug in the Bugzilla to stop this from falling between the cracks... Cheers, Paul. On Wed, 18 Feb 2004, Jeff Epler wrote: > for what it's worth, I've also noticed wine apps killing Xvfb. This was > with redhat 9's XFree86-Xvfb-4.3.0-2. > > We ended up changing from Xvfb to vncserver, both for this reason and > because an error condition can require user intervention with our wine app. > > I don't have any better test case, because ours involves a multi-megabyte > windows application. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
3D support for radeon 9600 pro (ppc)
I know there is already 2D support for the radeon 9600 pro in the upcoming 4.4 release. My question is if I buy an Apple Powermac G5 with a radeon 9600 pro card will I eventually in the future be able to get 3D support on the powerpc platform (not x86!!) ? För alla singlar - singelkryssen lättar ankar igen den 23 oktober. Boka nu! http://www.spray.se/datekryss
Re: i855GM: New BIOS breaks i810-driver]
>Christian Zietz writes: > > Hi, > > > > as developer of 855patch I get a lot of feedback from people using > > XFree86 on computers with i855GM graphics. > > It seems like new notebooks by Dell feature a new video BIOS from Intel > > (iirc Build 3066) which finally implements the int 0x10 0x5f11 function > > to set the amount of video RAM and thus making 855patch obsolete. > > > > But the i810-driver refuses to work on systems with that BIOS version. I > > had several independent reports of users who just get a completely green > > screen when starting XFree86. I had a look on a log file and found > > nothing unusual. The XFree86 VESA driver however works but just in low > > resolutions/color depths as there is no way to allocate more video RAM > > there. > > > > As I've been absent of this list: Is this already a known issue? > > > >I haven't heared anyting about this issue yet. >The first question that comes to my mind is: >What happens if a low resolution mode that works with VESA >is set on the i8xx driver? > >Egbert. Hi, I have the Dell Latitude D505 in question. It runs latest BIOS (v2) as posted by Dell on their web site. The video chipset is Intel 82852/855GM. I installed XFree86 4.4 RC3 with RH 9 kernel 2.4.20-30.9 (although I believe that the same problem occurs with XF86 4.3, but I didn't investigate in detail before upgrading). The monitor is XGA, capable of 1024x768 at 60 Hz. The symptoms are following; * 892 kB of video memory are reported by BIOS * vesa driver takes that amount and can run 1024x768x8 * i810 driver negotiates with BIOS for extra memory (the actual amount seems to depend on video modes specified in XF86Config, anywhere from 8-32 MB) * i810 driver freezes with green screen and the last line of log is; "(II) I810(0): 2 display pipes available." Soft reboot seems like the only way to regain the control of console (ALT-F1, etc. doesn't work, although keyboard seems responsive) By changing video modes I tried to "convince" i810 driver not to request extra video memory, but even for 640x400x8 (4 and 1 bit depth seem not to be supported by i810) it tries to allocate at least 8 MB. I'm attaching the logs (successful vesa and frozen i810) and config file (where I onlt toggle between driver in question). I hope this helps, -- ~ Predrag Miocinovic Section "ServerLayout" Identifier "XFree86 Configured" Screen 0 "Screen0" 0 0 InputDevice"Mouse0" "CorePointer" InputDevice"Keyboard0" "CoreKeyboard" EndSection Section "Files" RgbPath "/usr/X11R6/lib/X11/rgb" ModulePath "/usr/X11R6/lib/modules" FontPath "/usr/X11R6/lib/X11/fonts/misc/" FontPath "/usr/X11R6/lib/X11/fonts/TTF/" FontPath "/usr/X11R6/lib/X11/fonts/Speedo/" FontPath "/usr/X11R6/lib/X11/fonts/Type1/" FontPath "/usr/X11R6/lib/X11/fonts/CID/" FontPath "/usr/X11R6/lib/X11/fonts/75dpi/" FontPath "/usr/X11R6/lib/X11/fonts/100dpi/" EndSection Section "Module" Load "extmod" Load "dbe" Load "dri" Load "glx" Load "record" Load "xtrap" Load "speedo" Load "type1" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "keyboard" EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/mouse" Option "Emulate3Buttons" EndSection Section "Monitor" Identifier "Monitor0" VendorName "Dell" ModelName"Dell Laptop Display 1024x768" HorizSync31.5-48.5 VertRefresh 59-75 EndSection Section "Device" ### Available Driver options are:- ### Values: : integer, : float, : "True"/"False", ### : "String", : " Hz/kHz/MHz" ### [arg]: arg optional #Option "NoAccel" # [] #Option "SWcursor" # [] #Option "ColorKey" # #Option "CacheLines"# #Option "Dac6Bit" # [] #Option "DRI" # [] #Option "NoDDC" # [] #Option "ShowCache" # [] #Option "XvMCSurfaces" # #Option "PageFlip" # [] Identifier "Card0" #Driver "i810" Driver "vesa" VendorName "Intel Corp." BoardName "82852/855GM Integrated Graphics Device" BusID "PCI:0:2:0" EndSection Section "Screen" Identifier "Screen0" Device "Card0" Monitor"Monitor0" DefaultDepth 8 Subsection "Display" Depth 8 #Modes "1280x1024" "1024x768" "800x600" "640x480"
Re: Printer-builtin fontpaths broken / was: Re: CVS Update: xc (branch: trunk)
David Dawes wrote:
> >David Dawes wrote:
> >> CVSROOT:/home/x-cvs
> >> Module name:xc
> >> Changes by: [EMAIL PROTECTED] 04/02/11 13:11:26
> >>
> >> Log message:
> >>799. Some more font path checks.
> >>
> >> Modified files:
> >> xc/lib/font/fontfile/:
> >> dirfile.c encparse.c fontfile.c
> >> xc/programs/Xserver/hw/xfree86/:
> >> CHANGELOG
> >>
> >> Revision ChangesPath
> >> 3.18 +17 -1 xc/lib/font/fontfile/dirfile.c
> >> 1.20 +7 -2 xc/lib/font/fontfile/encparse.c
> >> 3.22 +30 -11xc/lib/font/fontfile/fontfile.c
> >> 3.3139+2 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG
> >
> >David:
> >Somehow these changes broke Xprt's handing of printer builtin fonts
> >(e.g. font paths prefixed with "PRINTER:" which are "enabled"
> >dynamically on per-model-config basis).
>
> Can you isolate which of the changes causes the problem by adding them
> in one at a time?
Yes, it seems that my original observation was wrong. Not the
printer-builtin fonts are affected but parts of the font path are
dropped.
The following statement in xc/lib/font/fontfile/dirfile.c causes the
failure:
(from
http://xprint.freedesktop.org/cgi-bin/bugzilla/attachment.cgi?id=95&action=view)
-- snip --
+ }
+ if (!found_font) {
+ FontFileFreeDir (dir);
+ fclose(file);
+ return BadFontPath;
}
-- snip --
It seems that the change now makes it mandatory that the Xserver allows
to drop invalid font path elements... ;-/
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [EMAIL PROTECTED]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 2426 901568 FAX +49 2426 901569
(;O/ \/ \O;)
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: i855GM: New BIOS breaks i810-driver - solved
Hi,
> > Christian Zietz writes:
> > Hi,
> >
> > as developer of 855patch I get a lot of feedback from people using
> > XFree86 on computers with i855GM graphics.
> > It seems like new notebooks by Dell feature a new video BIOS from Intel
> > (iirc Build 3066) which finally implements the int 0x10 0x5f11 function
> > to set the amount of video RAM and thus making 855patch obsolete.
> >
> > But the i810-driver refuses to work on systems with that BIOS version. I
> > had several independent reports of users who just get a completely green
> > screen when starting XFree86. I had a look on a log file and found
> > nothing unusual. The XFree86 VESA driver however works but just in low
> > resolutions/color depths as there is no way to allocate more video RAM
> > there.
> >
> > As I've been absent of this list: Is this already a known issue?
> >
>
> I haven't heared anyting about this issue yet.
> The first question that comes to my mind is:
> What happens if a low resolution mode that works with VESA
> is set on the i8xx driver?
>
> Egbert.
I've got this problem with the new Dell 510m model : with the normal i810
driver, we've got only a total green screen.
The problem comes from the call to INT 10h, 0x5f64 in the
GetDisplayInfo() function. It never returns.
As this function is only informative, I commented out its call in
I830DetectDisplayDevice() (XFree86 4.3.0.1) :
...
static Bool
I830DetectDisplayDevice(ScrnInfoPtr pScrn)
{
I830Ptr pI830 = I830PTR(pScrn);
int pipe, n;
DisplayType i;
#if 0
for (i = 0; i < NumKnownDisplayTypes; i++) {
if (GetDisplayInfo(pScrn, 1 << i, &pI830->displayAttached[i],
&pI830->displayPresent[i],
&pI830->displaySize[i].x2,
&pI830->displaySize[i].y2)) {
xf86DrvMsg(pScrn->scrnIndex, X_INFO,
"Display Info: %s: attached: %s, present: %s, size: "
"(%d,%d)\n", displayDevices[i],
BOOLTOSTRING(pI830->displayAttached[i]),
BOOLTOSTRING(pI830->displayPresent[i]),
pI830->displaySize[i].x2, pI830->displaySize[i].y2);
}
}
#endif
pI830->configuredDevices = GetDisplayDevices(pScrn);
if (pI830->configuredDevices == -1) {
xf86DrvMsg(pScrn->scrnIndex, X_INFO,
"Failed to detect active display devices\n");
return FALSE;
}
...
Now all is working fine (except the fact that the 1500x1040 resolution
is still not reconized by the bios).
I hope this help.
Regards
PS : not more need to use 855Patch with this bios.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: 3D support for radeon 9600 pro (ppc)
jaspal kallar wrote: I know there is already 2D support for the radeon 9600 pro in the upcoming 4.4 release. My question is if I buy an Apple Powermac G5 with a radeon 9600 pro card will I eventually in the future be able to get 3D support on the powerpc platform (not x86!!) ? Only if ATI ports their closed-source driver to PowerPC. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: i855GM: New BIOS breaks i810-driver - solved
On Thu, Feb 19, 2004 at 11:17:03PM +0100, Alain POIRIER wrote:
> Hi,
>
> > > Christian Zietz writes:
> > > Hi,
> > >
> > > as developer of 855patch I get a lot of feedback from people using
> > > XFree86 on computers with i855GM graphics.
> > > It seems like new notebooks by Dell feature a new video BIOS from Intel
> > > (iirc Build 3066) which finally implements the int 0x10 0x5f11 function
> > > to set the amount of video RAM and thus making 855patch obsolete.
> > >
> > > But the i810-driver refuses to work on systems with that BIOS version. I
> > > had several independent reports of users who just get a completely green
> > > screen when starting XFree86. I had a look on a log file and found
> > > nothing unusual. The XFree86 VESA driver however works but just in low
> > > resolutions/color depths as there is no way to allocate more video RAM
> > > there.
> > >
> > > As I've been absent of this list: Is this already a known issue?
> > >
> >
> > I haven't heared anyting about this issue yet.
> > The first question that comes to my mind is:
> > What happens if a low resolution mode that works with VESA
> > is set on the i8xx driver?
> >
> > Egbert.
>
> I've got this problem with the new Dell 510m model : with the normal i810
> driver, we've got only a total green screen.
>
> The problem comes from the call to INT 10h, 0x5f64 in the
> GetDisplayInfo() function. It never returns.
>
> As this function is only informative, I commented out its call in
> I830DetectDisplayDevice() (XFree86 4.3.0.1) :
>
> ...
> static Bool
> I830DetectDisplayDevice(ScrnInfoPtr pScrn)
> {
>I830Ptr pI830 = I830PTR(pScrn);
>int pipe, n;
>DisplayType i;
>
> #if 0
>for (i = 0; i < NumKnownDisplayTypes; i++) {
> if (GetDisplayInfo(pScrn, 1 << i, &pI830->displayAttached[i],
> &pI830->displayPresent[i],
> &pI830->displaySize[i].x2,
> &pI830->displaySize[i].y2)) {
> xf86DrvMsg(pScrn->scrnIndex, X_INFO,
> "Display Info: %s: attached: %s, present: %s, size: "
> "(%d,%d)\n", displayDevices[i],
> BOOLTOSTRING(pI830->displayAttached[i]),
> BOOLTOSTRING(pI830->displayPresent[i]),
> pI830->displaySize[i].x2, pI830->displaySize[i].y2);
> }
>}
> #endif
>
>pI830->configuredDevices = GetDisplayDevices(pScrn);
>if (pI830->configuredDevices == -1) {
> xf86DrvMsg(pScrn->scrnIndex, X_INFO,
> "Failed to detect active display devices\n");
> return FALSE;
>}
Alain,
That's good to know. This call to GetDisplayInfo isn't strictly needed,
but it's useful information to find out about the attached displays.
It's probably wise if we make this an option in the driver and turn
it off by default.
Alan.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: i855GM: New BIOS breaks i810-driver - solved
Alain, Can you try the int10 emulator ? To do this, (re)move this file out of the way. /usr/X11R6/lib/modules/linux/libint10.a Then XFree86 will use /usr/X11R6/lib/modules/libint10.a Which is the emulator. Does it still lockup with that BIOS call ? Alan. ___ Devel mailing list [EMAIL PROTECTED] 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
lockups
I've complained about lockups in the past. I have uninstalled xscreensaver 4.14 and my PC has not locked up for two days so far. What worries me is that a poorly writen or buggy program can lock up my machine hard so that only a hard reset will cure it. I am using: XFree86 Version 4.3.99.902 (4.4.0 RC 2) Release Date: 18 December 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.6.1 i686 [ELF] Current Operating System: Linux pc1 2.6.3-rc3 #4 SMP Sun Feb 15 10:11:45 EST 2004 i686 Build Date: 23 January 2004 Changelog Date: 23 January 2004 Before reporting problems, check http://www.XFree86.Org/ to make sure that you have the latest version. Module Loader present Fred Error Loading Explorer.exe You must reinstall Windows. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: lockups
Fred Heitkamp wrote: I've complained about lockups in the past. I have uninstalled xscreensaver 4.14 and my PC has not locked up for two days so far. What worries me is that a poorly writen or buggy program can lock up my machine hard so that only a hard reset will cure it. A program can't do that. A driver can, however, by feeding incorrect data to the graphics hardware. xscreensaver is one of the most stressful programs you'll ever find for graphics drivers. It does more high-speed and edge-condition 2D graphics than any other program you're likely to run. A scrolling xterm is a piece of cake compared to some of the wild hacks in xscreensaver. I am using: XFree86 Version 4.3.99.902 (4.4.0 RC 2) Release Date: 18 December 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.6.1 i686 [ELF] Current Operating System: Linux pc1 2.6.3-rc3 #4 SMP Sun Feb 15 10:11:45 EST 2004 i686 Build Date: 23 January 2004 Interesting, but you left out the most critical piece of information: what graphics chip and driver? -- - Tim Roberts, [EMAIL PROTECTED] Providenza & Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: lockups
Xscreensaver uses OpenGL for many of the screensavers. It's most likely OpenGL driver bugs. Mark. On Thu, 19 Feb 2004, Fred Heitkamp wrote: > I've complained about lockups in the past. > I have uninstalled xscreensaver 4.14 and my PC has not locked up for two > days so far. What worries me is that a poorly writen or buggy program can > lock up my machine hard so that only a hard reset will cure it. I am > using: > > XFree86 Version 4.3.99.902 (4.4.0 RC 2) > Release Date: 18 December 2003 > X Protocol Version 11, Revision 0, Release 6.6 > Build Operating System: Linux 2.6.1 i686 [ELF] > Current Operating System: Linux pc1 2.6.3-rc3 #4 SMP Sun Feb 15 10:11:45 > EST 2004 i686 > Build Date: 23 January 2004 > Changelog Date: 23 January 2004 > Before reporting problems, check http://www.XFree86.Org/ > to make sure that you have the latest version. > Module Loader present > > > Fred > > Error Loading Explorer.exe > You must reinstall Windows. > ___ > Devel mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/devel > ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
