4.4.0 RC2 and linux 2.6.3-rc1
Hi, I tried latest kernel and I see some error logged by the system, Should I worry? atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0). atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly. atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0). atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly. -- Martin Mokrejs [EMAIL PROTECTED] PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Fwd: [Xorg-commit] xc/lib/font/fontfile dirfile.c,1.1.4.2,1.1.4.3
On Sat, Feb 07, 2004 at 09:58:56PM -0800, Alan Coopersmith wrote: David Dawes wrote: The fix was being held to allow for a coordinated release of the Perhaps if someone from XFree86 had contacted the X.org security list to notify the other X vendors that this issue was being coordinated, it would have been handled properly. Who exactly does the coordinating and how are vendors supposed to be notified? My understanding is that several X.Org member companies have representatives on the relevant notification channels. There seems to be an internal communications problem here. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Fwd: [Xorg-commit] xc/lib/font/fontfile dirfile.c,1.1.4.2,1.1.4.3
David Dawes wrote: On Sat, Feb 07, 2004 at 09:58:56PM -0800, Alan Coopersmith wrote: David Dawes wrote: The fix was being held to allow for a coordinated release of the Perhaps if someone from XFree86 had contacted the X.org security list to notify the other X vendors that this issue was being coordinated, it would have been handled properly. Who exactly does the coordinating and how are vendors supposed to be notified? My understanding is that several X.Org member companies have representatives on the relevant notification channels. There seems to be an internal communications problem here. What relevant notification channels was this sent to? Obviously there was some breakdown, since we didn't get notified through those channels. -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc.- Sun Software Group User Experience Engineering: G11N: X Window System ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 4.4.0 RC2 and linux 2.6.3-rc1
On Sun, 8 Feb 2004, [iso-8859-2] Martin MOKREJ© wrote: I tried latest kernel and I see some error logged by the system, Should I worry? atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0). atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly. atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0). atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly. This happens on 4.3.0 also, and is due to the X server directly bit banging the keyboard controller to set the repeat rate. If you look at the code, it first tries to use the new kernel ioctl, then a fallback, then finally it does bitbanging if the previous methods fail. The kernel people believe that it should not ever directly access the hardware, and that it should only use the ioctl, and if the ioctl isn't available in your kernel (perhaps your kernel is very very ancient), then X should not set the repeat rate at all. The question then is: Why is the ioctl not working? I am currently investigating this matter myself, and there are a few possibilities that could be happening: 1) Compile time problem: The kernel headers on the machine that X is being compiled on, do not have the KDKBDRATE ioctl present, and so the code to use that ioctl does not get compiled in. or 2) The KDKBDRATE ioctl stuff gets built in, but at runtime the ioctl is failing for some reason or another, thus the ioport bitbanging occurs, and can totally hang the machine according to kernel folk. If anyone has any other possibilities, feel free to share. I've written a small debugging patch to put into a future build in order to peek into what's going on, but haven't gotten it into test builds yet. Not an uber-high priority item however, so it'll take a week or two probably for a test build to get out there and get some feedback from people seeing this problem. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Delivery Status Notification (Failure)
Your message To: [EMAIL PROTECTED] Subject: hi Sent:Sun, 8 Feb 2004 22:56:59 +0200 did not reach the following recipient(s): [EMAIL PROTECTED] on Sun, 8 Feb 2004 22:57:23 +0200 The e-mail account does not exist at the organization this message was sent to. Check the e-mail address, or contact the recipient directly to find out the correct address. atvex.atv.com.tr #5.1.1 Reporting-MTA: dns; atvex.atv.com.tr Final-Recipient: RFC822; [EMAIL PROTECTED] Action: failed Status: 5.1.1 X-Supplementary-Info: atvex.atv.com.tr #5.1.1 X-Display-Name: [EMAIL PROTECTED] ---BeginMessage--- The message contains Unicode characters and has been sent as a binary attachment. REMOVED_BY_THE_EXCHANGE_EMAIL_SCANNING_SERVICE_5CAE6CF4_4D03_48A0.txt Description: REMOVED_BY_THE_EXCHANGE_EMAIL_SCANNING_SERVICE_5CAE6CF4_4D03_48A0.txt ---End Message---
Memory already used?
Hi, I'm a bit playing around with my comp and finally figured out why on one host I did not get framebuffer on console running - the VESA kernel module wasn't compiled into kernel. So now I have framebuffer console, but X don't start anymore. They used to work with radeon module and dri, but the log doesn't show anything interresting. Fatal server error: AddScreen/ScreenInit failed for driver 0 So I tried vesa module and they do come up after some flashes of the screen and there is some suspicious WW message: VESA(0): Failed to setup write-combining range What's that? Could that be a reason why X don't come up with radeon module at all? dmesg(1) shows: Linux agpgart interface v0.100 (c) Dave Jones radeon: no version for struct_module found: kernel tainted. radeon: no version magic, tainting kernel. [drm] Initialized radeon 1.10.0 20020828 on minor 0: ATI Radeon RV280 9200 mtrr: 0xd000,0x800 overlaps existing 0xd000,0x100 Full logs are at: http://www.natur.cuni.cz/~mmokrejs/lspci.txt.gz http://www.natur.cuni.cz/~mmokrejs/XFree86.0.log.gz These errors I get regardless the fact agpgart/radeon kernel modules are loaded. Could the problem be caused by the 1:0:1 device unrecognized (the AGP card has 1:0:0 and 1:0:1 address)? Thanks -- Martin Mokrejs [EMAIL PROTECTED] PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Newbie question, difference between offscreen and onscreen image formats?
Sent: Saturday, February 07, 2004 6:29 PM Subject: Re: Newbie question, difference between offscreen and onscreen image formats? The image formats registered via xf86XVScreenInit are ones that are exported to the clients. The ones registered via xf86XVRegisterOffscreenImages are for internal use only. The idea being that they are the hardware's native overlay format or formats that can be exposed to other parts of the server such as a module which uses V4L. Reasons why some formats would be exposed as client XvImages while they wouldn't be exposed as OffscreenImages could be: * The XvImage formats aren't implemented via the overlay, but with some texture or blit mechanism. * The XvImage formats, though using the overlay, aren't the native hardware format and require CPU reformating on the copy. * There are hardware or software complications related to other devices bus mastering data into those overlay formats. * Simply an oversight, or somebody just didn't get around to adding them, or didn't have a way to adequetly test them. Thanks for the explaination. I know chiip and tech 69000/69030 supports both YUV and RGB overlays. So I guess, all the formats should also be registered as offscreen formats. Any idea what else needs to be changed? Like which functions get called to set/start/stop/capture overlays. Or should I contact one of the chips driver's developer? Suhaib ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Dri-devel] GL_VERSION 1.5 when indirect rendering?
Am 2004.02.07 09:44:39 +0100 schrieb(en) Ian Romanick: [...] as well. I'll try to have a patch tomorrow. The server-side of things Looks like its fixed in DRI CVS with/since your patch. I have to admit that I only tried with the new libGL.so and old Xserver/libs, not with old libGL and new Xserver. OpenGL version string: 1.2 (1.5 Mesa 6.1) [...] think it needs the Ultimate Refactor...'rm -rf programs/Xserver/GL' ... and I was told 'rm -rf' means read mail, really fast! ;) greetings, Andreas ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Dri-devel] GL_VERSION 1.5 when indirect rendering?
On Sat, Feb 07, 2004 at 12:44:39AM -0800, Ian Romanick wrote: I like it. :) It looks a little weird to me like that, but I think doing 1.2 (1.4.20040108 Foobar, Inc. Fancypants GL) should work just as well. I would want to be very sure that there are no apps parsing that string before making such a change. Granted it's more likely they'll be looking at the RENDERER string. Jon Leech SGI ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
