Re: Prefer nvidia over nv when available
Hi David, |--==> David Nusinow writes: [...] DN> The idea for the future is that all the drivers will export a symbol table DN> of the PCI ID's they support. The server will scan them for drivers DN> supporting the required PCI ID. My plan is to have them export an DN> additional symbol table consisting of driver names that they override. So DN> nvidia would export an override table with "nv" in it. Cool, pretty much like kernel some modules then. DN> The notable thing about this is that it exists entirely outside the DN> packaging system, so it's entirely up to upstream. That is a Good Thing :) DN> In the case of the DN> various nvidia drivers, if the legacy drivers are updated to include these DN> symbols then they'll be automatically loaded if they're available. If not, DN> then the server will load something else (nv if available, or an DN> arch-specific fallback like vesa if not). DN> So, if Nvidia decides to update their drivers, they'll get the benefits of DN> this. Let's say that, in the best case scenario, that Nvidia updates both their new and legacy drivers (71xx,96xx). Still the relevant Debian packages can't be installed at same time (as they are now), so the proper nvidia driver sporting the proper PCI ID might not be available on the system. Is there a workaround for this? For example in the Debian package for a legacy driver one could change the path of the file of the nvidia xorg driver, from: /usr/lib/xorg/modules/drivers/nvidia_drv.so to /usr/lib/xorg/modules/drivers/nvidia_drv-96xx-.so so that the package doesn't conflict anymore with the other nvidia driver packages. Or other tricks like this one. Would this work/make sense? DN> The PCI ID symbol table thing already exists upstream in the xserver DN> master branch, but the code to auto-load the driver based on it doesn't DN> exist yet, but that's my goal for next week. In the worst-case scenario, DN> Nvidia won't add the necessary symbols and users will just have to edit DN> their xorg.confs the same way they did in the past. In the worst case scenario of Nvidia not updating their drivers (or updating only the new one and not the legacy ones), what could be done to avoid the user to edit directly the xorg.conf file? Ciao, Free -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Prefer nvidia over nv when available
Hi David, |--==> David Nusinow writes: DN> On Mon, Oct 01, 2007 at 11:30:26PM +0200, Free Ekanayaka wrote: >>Hi all, >> >>is there a way to instruct the script(s) that generate the xorg.conf >>file at installation time to prefer nvidia over nv when the first is >>available? (and possibly to mark the proper packages for installation >>when not already installed). DN> Not currently but it is definitely something I'm planning to do. Since I'm DN> going to scrap that section of the debconfage soon, adding the feature DN> there is pretty useless. The solution we currently have is a temporary one DN> due to changes upstream, but I'll be implementing things upstream over the DN> next few weeks, and I'll follow it up with this sort of feature so that DN> nvidia can override nv by default when they're both installed (if the DN> nvidia developers decide that's what they want anyway). Thanks. Just a few questions, if you already know the answer. Beside the regular nvidia-glx package and the relevant kernel module package would this mechanism also support the various other packages of the nvidia driver currently available in sid (e.g. legacy-71xx and legacy-96xx)? These different nvidia packages conflict with each other, so it might happen that the correct nvidia package is not installed by the time the xorg packages run their debconf script. How would this situation be handled? Ciao! Free -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Prefer nvidia over nv when available
Hi all, is there a way to instruct the script(s) that generate the xorg.conf file at installation time to prefer nvidia over nv when the first is available? (and possibly to mark the proper packages for installation when not already installed). Thanks, Free -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#400181: Silicon Motion chip on amd64
|--==> Alex Deucher writes: AD> Sorry, for the delay, I've been busy with other things and I haven't AD> gotten around to siliconmotion in a while. I'll try and put something AD> together this week and do a siliconmotion driver release. thanks for your fast reply. If you can make it for this week, it's wonderful! however the release process of the next Debian is a bit late, so I think we have still some weeks. Ciao! Free -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#400181: Silicon Motion chip on amd64
Hi Alex, I'm the reporter of the bug about the misbehaviour of the silicon driver with the Silicon Motion chip on amd64 architecture. I take the liberty to contact you directly.. Did you have a chance to work on the issue? I'm still using the quick & dirty patch you provided me a while ago, and as it works well for me I've tried to propose its inclusion in the Debian package for the silicon X driver: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=400181 However, as that patch cleary not an optimal solutio, the Debian maintainer of the package does't feel like including it. As we are now approaching to the next Debian release (called Etch), it will be great if you could provide a better patch, so that it can be included in time. Thanks! Free -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#400181: xserver-xorg-video-siliconmotion: Xorg hangs on amd64 with Silicon Motion chip
Package: xserver-xorg-video-siliconmotion Version: 1:1.3.1.5-3 Severity: important Tags: patch Hi, the driver hangs on a Debian/amd64 system with the Silicon Motion SM720 Lynx3DM (ID 126f:0720) card. I've asked help on the Xorg mailing list and I got attached patch which fixes the problem: However the patch has not yet been included upstream, so I'd really like to see it applied in the Debian package, possibly before etch comes out. Thanks! Free --- ./src/smi_driver.c 2006-11-13 14:11:11.0 -0500 +++ ./src/smi_driver.c 2006-11-13 14:20:00.0 -0500 @@ -1508,7 +1508,7 @@ vgaHWProtect(pScrn, TRUE); /* Wait for engine to become idle */ - WaitIdle(); + /* WaitIdle(); */ if (pSmi->useBIOS && (pSmi->pInt10 != NULL) && (restore->mode != 0))
Silicon Motion chip on amd64 [part 2]
a few days ago I've posted here this message http://lists.debian.org/debian-x/2006/09/msg01286.html but got no reply. So, I've tried to contact debian-amd64, and I was suggested to remove the NVIDIA card and possibly contact again this list with further details: http://lists.debian.org/debian-amd64/2006/10/msg00015.html I've tried to follow the hint which has been given meon the debian-amd64 list, but it didn't work, see my reply here: http://lists.debian.org/debian-amd64/2006/10/msg00020.html Any hint? Ciao, Free -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Silicon Motion chip on amd64
Hi all, I can't get xorg working with the Silicon Motion, Inc. SM720 Lynx3DM (rev c1), ID 126f:072, VGA controller on a etch/amd64 system. Note that the same hardware works fine with etch/i386. Here is the output of lscpi, the xorg.conf, and Xorg.0.log: http://people.64studio.com/~free/xorg.conf http://people.64studio.com/~free/lspci.output http://people.64studio.com/~free/Xorg.0.log I've tried both with xserver-xorg 7.0 and 7.1 any hint? Ciao, Free -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#370033: x11-common: bash profile not read when opening an X session
Package: x11-common Version: 6.9.0.dfsg.1-5 Severity: wishlist Hi, this is basically a forward of a feature request I've received for 64 Studio, a custom debian distrbution I maintain. The original ticket is http://www.64studio.com/ticket/107 The issue can be fixed by installing the attached file in /etc/X11/Xsession.d/15x11-common_shell-profile Thanks, Free 1564studio-skel_shell_profile Description: application/shellscript
Bug#369389: xresprobe: Regression between 0.4.18-1 and 0.4.23debian1 on a HP Pavillon zv5000
Package: xresprobe Version: 0.4.23debian1 Severity: normal Hi, I'm running bleeding-edge etch on my laptop HP Pavillon zv5000. The latest xresprobe version 0.4.23debian1 seems to fail to detect the proper resolution: [EMAIL PROTECTED]:/# xresprobe nv grep: /tmp/xprobe.19627/xorg.log: No such file or directory grep: /tmp/xprobe.19627/xorg.log: No such file or directory id: res: freq: disptype: lcd/lvds Note that version 0.4.18-1 is working fine: [EMAIL PROTECTED]:/# xresprobe nv id: res: 1280x800 freq: disptype: lcd/lvds I've tried to upgrade to sid and this time xresprobe 0.4.23debian1 works nicely: [EMAIL PROTECTED]:/# xresprobe nv id: res: 1280x800 freq: disptype: lcd/lvds It probably means that you should depend on higher versions of some packages.. Cheers, Free -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#322920: Please raise severity of x11-common bug
|--==> Guenter Geiger writes: GG> Hi, GG> This is definitely not a bug of x11-common. GG> I understand both points of view, and emotionally I rather would follow my GG> Debian feelings. GG> It is not possible to check if all Debian packages in the world (outside GG> Debian) are conflicting with the official Debian package. GG> In this sense, it is up to the split-off distribution (Ubuntu, Demudi) to GG> handle the bug and guarantee a smooth upgrade for their thing. GG> You knew that when you decided to use non-official packages, right ? GG> On the other hand, it might be a good idea to offer a path back to GG> Debian for those who went abroad, especially if the problem can be GG> fixed together with bug #318688. Sorry for replying so lately.. As a general rules A/DeMuDi tries to stick to Debian as much as possible. I've included the xorg package in A/DeMuDi 1.2.1, because at that time there was no Debian xorg package; the xorg server and the kernel are the only significant "forks" from Debian (sarge) . Guenter is right, when you split-off you have the responsibility of what you do. When a new release of A/DeMuDi will approach I'll take care of possibly upgrability issues as this. Cheers, Free -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
