Re: [ANNOUNCE] Deprecation of xf86-video-nv
On Friday 26 of March 2010, Andy Ritger wrote: Our advice to owners of NVIDIA GPUs running Linux is to use the VESA X driver from the time of Linux distribution installation While others advice is to use nouveau driver [1] (going to be) shipped by latest distibution releases instead of vesa or nvidia binary blob. Thanks, Andy Ritger 1. http://nouveau.freedesktop.org/ -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] Deprecation of xf86-video-nv
On Mon, 29 Mar 2010, Andy Ritger wrote: On Sat, 27 Mar 2010, Piotr Gluszenia Slawinski wrote: -- On Fri, 26 Mar 2010, Andy Ritger wrote: Historically, NVIDIA developed and maintained the xf86-video-nv X driver, Our advice to owners of NVIDIA GPUs running Linux is to use the VESA X driver from the time of Linux distribution installation until they can download and install the NVIDIA Linux driver from their distribution repositories or from nvidia.com. then NVIDIA could be so kind and fix the NVIDIA Linux driver to build and work properly with alternate libc implementations, like uclibc (glibc is hard-linked in libGL supplied with The Driver) Hello, Piotr. No, glibc is not statically linked into NVIDIA's libGL.so, if that is what you mean to imply. no, it just expects glibc being in the system. If uclibc provided the same ABI as glibc then I would expect NVIDIA's libGL.so to work with uclibc. However, my understanding is that binary compatiblity (either with glibc or even with prior uclibc releases) is a non-goal of the uclibc project. yes, it is not binary-compatible glibc. For better or worse, the NVIDIA driver is provided as binary-only, so it is not terribly well suited to deal with system library binary interface changes. Sorry, - Andy well, and that is what i'm complaining about... mind you glibc will not be always binary compatible either across it's own versions - same as libc5 to glibc (libc6) transition occured ad some point... this limits nvidia driver usage to specific libc implementation, with specific version. nv driver itself served well for i.e. people who could sacrifice 3d performance in i.e. netbooks, where they would rather focus on battery and storage usage when choosing libc implementation. if it quits being maintained and users are advised to move to binary driver - it would be nice to make it actually compile on such systems... p.s. why nvidia does not set up some price levels on opening parts of drivers like i.e. blender coders did? -- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How to arbitrarily manipulate key events in X
A manipulation possibility as you describe it would be even better. From what I understand, the X Event Interception Extension once has been a way, but according to the Xorg Wiki, it is dead. Is there any way to do what XEvIE did? Some have suggested XInput2 could replace it. How mature is this method? //meingbg ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
[no subject]
please delet me from the mailing list.thx -- GMX.at - Österreichs FreeMail-Dienst mit über 2 Mio Mitgliedern E-Mail, SMS mehr! Kostenlos: http://portal.gmx.net/de/go/atfreemail ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re:
On Tue, Mar 30, 2010 at 9:06 AM, Tom Tiger bluetr...@gmx.net wrote: please delet me from the mailing list.thx You can only do that yourself. The link to do so is at the bottom of every email ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg See Info link above. ~David ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] Deprecation of xf86-video-nv
On Tue, Mar 30, 2010 at 7:31 PM, Piotr Gluszenia Slawinski curi...@bwv190.internetdsl.tpnet.pl wrote: On Mon, 29 Mar 2010, Andy Ritger wrote: On Sat, 27 Mar 2010, Piotr Gluszenia Slawinski wrote: -- On Fri, 26 Mar 2010, Andy Ritger wrote: Historically, NVIDIA developed and maintained the xf86-video-nv X driver, Our advice to owners of NVIDIA GPUs running Linux is to use the VESA X driver from the time of Linux distribution installation until they can download and install the NVIDIA Linux driver from their distribution repositories or from nvidia.com. then NVIDIA could be so kind and fix the NVIDIA Linux driver to build and work properly with alternate libc implementations, like uclibc (glibc is hard-linked in libGL supplied with The Driver) Hello, Piotr. No, glibc is not statically linked into NVIDIA's libGL.so, if that is what you mean to imply. no, it just expects glibc being in the system. If uclibc provided the same ABI as glibc then I would expect NVIDIA's libGL.so to work with uclibc. However, my understanding is that binary compatiblity (either with glibc or even with prior uclibc releases) is a non-goal of the uclibc project. yes, it is not binary-compatible glibc. For better or worse, the NVIDIA driver is provided as binary-only, so it is not terribly well suited to deal with system library binary interface changes. Sorry, - Andy well, and that is what i'm complaining about... mind you glibc will not be always binary compatible either across it's own versions - same as libc5 to glibc (libc6) transition occured ad some point... this limits nvidia driver usage to specific libc implementation, with specific version. nv driver itself served well for i.e. people who could sacrifice 3d performance in i.e. netbooks, where they would rather focus on battery and storage usage when choosing libc implementation. if it quits being maintained and users are advised to move to binary driver - it would be nice to make it actually compile on such systems... Just to posit, if you are intending on installing the nvidia binary driver on a niche built by hand system, then I don't think the glibc overheads would give you much cause. Wierdly you'd have gotten better battery life most likely using the binary driver since -nv doesn't have any powersaving abilities. So you are probably shooting yourself in the face to spite your foot or something. Dave. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] Deprecation of xf86-video-nv
On Wed, 31 Mar 2010, Dave Airlie wrote: On Tue, Mar 30, 2010 at 7:31 PM, Piotr Gluszenia Slawinski curi...@bwv190.internetdsl.tpnet.pl wrote: On Mon, 29 Mar 2010, Andy Ritger wrote: On Sat, 27 Mar 2010, Piotr Gluszenia Slawinski wrote: -- On Fri, 26 Mar 2010, Andy Ritger wrote: Historically, NVIDIA developed and maintained the xf86-video-nv X driver, Our advice to owners of NVIDIA GPUs running Linux is to use the VESA X driver from the time of Linux distribution installation until they can download and install the NVIDIA Linux driver from their distribution repositories or from nvidia.com. then NVIDIA could be so kind and fix the NVIDIA Linux driver to build and work properly with alternate libc implementations, like uclibc (glibc is hard-linked in libGL supplied with The Driver) Hello, Piotr. No, glibc is not statically linked into NVIDIA's libGL.so, if that is what you mean to imply. no, it just expects glibc being in the system. If uclibc provided the same ABI as glibc then I would expect NVIDIA's libGL.so to work with uclibc. However, my understanding is that binary compatiblity (either with glibc or even with prior uclibc releases) is a non-goal of the uclibc project. yes, it is not binary-compatible glibc. For better or worse, the NVIDIA driver is provided as binary-only, so it is not terribly well suited to deal with system library binary interface changes. Sorry, - Andy well, and that is what i'm complaining about... mind you glibc will not be always binary compatible either across it's own versions - same as libc5 to glibc (libc6) transition occured ad some point... this limits nvidia driver usage to specific libc implementation, with specific version. nv driver itself served well for i.e. people who could sacrifice 3d performance in i.e. netbooks, where they would rather focus on battery and storage usage when choosing libc implementation. if it quits being maintained and users are advised to move to binary driver - it would be nice to make it actually compile on such systems... Just to posit, if you are intending on installing the nvidia binary driver on a niche built by hand system, then I don't think the glibc overheads would give you much cause. Wierdly you'd have gotten better battery life most likely using the binary driver since -nv doesn't have any powersaving abilities. So you are probably shooting yourself in the face to spite your foot or something. yes, current state of nvidia driver(s) make such choice bad. glibc overhead is not something 'worth' the 'powersaving abilities' in many cases, so best choice is usually to just get laptop with other GPU chipset, and use whatever one feels works best to him, despite being 'niche' . i'm not going to discuss performance issues of such setup on this group as this is largedly offtopic, recalling also times of libc5 transition, when there was large group of people not believing 'heavy' glibc implementation will be ever used by larger group of users... also linux is 'niche' system in general , so this makes little point. my point of above is that encouraging users to use driver which does not compile on plenty of systems, and is limited in future development by simple design flaw , will generate lot of un-satisfied users. it is not impossible thing to fix it, while there is still anyone caring to maintain the driver (note many cards will be 'obsoleted' by nvidia pretty soon and people will be left on their own with the drivers... better them be as flexible and adaptable for system upgrades as possible) -- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] Deprecation of xf86-video-nv
On Tue, Mar 30, 2010 at 5:31 AM, Piotr Gluszenia Slawinski curi...@bwv190.internetdsl.tpnet.pl wrote: well, and that is what i'm complaining about... mind you glibc will not be always binary compatible either across it's own versions - same as libc5 to glibc (libc6) transition occured ad some point... libc5 wasn't even glibc. It was the Linux libc. Read the glibc wikipedia article. this limits nvidia driver usage to specific libc implementation, with specific version. glibc is kind of the de facto libc. What do you expect here? Them not to link to the C library? Provide a second binary linking against uclibc? And what then about all the other libc's? Matt ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] Deprecation of xf86-video-nv
Am 30.03.10, 08:11 +0200 schrieb Arkadiusz Miskiewicz: On Friday 26 of March 2010, Andy Ritger wrote: Our advice to owners of NVIDIA GPUs running Linux is to use the VESA X driver from the time of Linux distribution installation While others advice is to use nouveau driver [1] (going to be) shipped by latest distibution releases instead of vesa or nvidia binary blob. Thanks, Andy Ritger 1. http://nouveau.freedesktop.org/ What kind of hardware documentation from nvidia would help to develop the open source driver? kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] Deprecation of xf86-video-nv
On Tue, Mar 30, 2010 at 10:33:01PM -0400, Matt Turner wrote: this limits nvidia driver usage to specific libc implementation, with specific version. glibc is kind of the de facto libc. What do you expect here? Them not to link to the C library? Provide a second binary linking against uclibc? And what then about all the other libc's? In fact, that was the problem we (DragonFly) run into back in the early days. Getting the kernel module to work as one issue. But as soon as the libc ABI divergated from the FreeBSD (4.x) ABI and the latter the 5.x only libGL, all things were lost. In short, the libGL is more painful part of the nvidia blob... Joerg ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
