https://bugzilla.novell.com/show_bug.cgi?id=339707 Summary: Nvidia geforce 8300 GS Product: openSUSE 10.3 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: SaX2 AssignedTo: ms@novell.com ReportedBy: rob.opensuse.linux@googlemail.com QAContact: qa@suse.de Found By: --- Currently install configures this card as a vesafb device, the monitor info seems not to be queried and display option is low resolution, and due to vesafb is noticeably slow. In https://bugzilla.novell.com/show_bug.cgi?id=339640 I reported issue attempting install of 3D driver, post YOU kernel security update. But that's been 'RESOLVED' and I don't seem to have way to re-open it, though I feel the real problem has not been addressed. Though that's marked resolved, the real problem has not been addressed : 1) nvidia rpm Istalling into wrong /lib/module/<kernel> tree and silently without warning. That can lead to hours wasted time, with sax2 & X11 Config when, the rpm script can check easy enough that you are running that kernel. On this occasion I may be able to ln(1) the kernel modules, into the new tree, but each security update is going to break the graphics driver if I use 'nvidia', so using binary module delivered is not really a 'solution' but an ongoing problem. It is not clear to me who builds the SuSE rpm's, Nvidia or a SuSE employee so I am not sure whether to lodge a bug report with them. 2) nv OSS driver This is 2D and non-tainted, furthermore generally acceptable for my workload, seeming superior to VESA. Any way of getting that working, or is it an Xorg 7.3 feature, with rpm's on their way after release? 3) kernel rpm and binary 3D ATI/Nvidia modules can share some code that checks on install for likely issues, reporting back to user; that the graphics driver is broken because of binary module issue. Suggesting using src rpm for the kernel-nvidia interface, or using 2D option till 3D tainted driver has been updated, would be more helpful. This would be acheivable by a 'kernel-hooks' directory, so post-install, registered rpm's can have a script run, explaining that they're broken and what to do about it. Stefan, I know (remember) you have worked with SaX2 and graphics for very many years, but the issue is when a kernel update breaks graphics (month or two later after installation), you support that machine but it is at a different site, and for some reason 3D graphics is required. You cannot rely on useful problem report, nor the machine being kept up for remote access, once the users decide that it's broken. Also due to 'security' advisories, there is a sense of FUD, if something happens around update time. Perhaps you see why the best solution is not to use a tainted 3D driver? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.