Re: server crash on linux-mips
On Mon, Feb 17, 2003 at 12:10:16AM +, Alan Hourihane wrote: If you call the ShadowFBInit2 in newport_driver.c (just tag FALSE on the end of the arguments). Does that work for you ? Yes, this works. Thanks! But it's significantly slower. After switching back from the console there's nothing happenning for about 5 seconds (but I see an half updated screen), then inistantly everything is back to normal. My question is now: is ShadowFBInit going to be removed in favor of ShadowFBInit2 or will it be revived? Should I look into fixing it or send a patch that uses ShadowFBInit2 (which would hopefully slip into 4.3.0)? shadowfb.h says about ShadowfbInit2: * It also allows you to specify that you * actually do have a real framebuffer (as opposed to just some malloc'd space * in memory) by passing FALSE to fbIsVirtual. But when I pass TRUE (since I only have a virtual fb and can't access the newports fb directly) it doesn't work. I have to pass FALSE. Am I missing something here? Thanks again, -- Guido ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: server crash on linux-mips
On Mon, Feb 17, 2003 at 10:23:03PM +0100, Guido Guenther wrote: On Mon, Feb 17, 2003 at 12:10:16AM +, Alan Hourihane wrote: If you call the ShadowFBInit2 in newport_driver.c (just tag FALSE on the end of the arguments). Does that work for you ? Yes, this works. Thanks! But it's significantly slower. After switching back from the console there's nothing happenning for about 5 seconds (but I see an half updated screen), then inistantly everything is back to normal. The expose events sent, should be fairly immediate, I don't know why it would take 5 seconds. My question is now: is ShadowFBInit going to be removed in favor of ShadowFBInit2 or will it be revived? Should I look into fixing it or send a patch that uses ShadowFBInit2 (which would hopefully slip into 4.3.0)? Yes send a patch in. shadowfb.h says about ShadowfbInit2: * It also allows you to specify that you * actually do have a real framebuffer (as opposed to just some malloc'd space * in memory) by passing FALSE to fbIsVirtual. But when I pass TRUE (since I only have a virtual fb and can't access the newports fb directly) it doesn't work. I have to pass FALSE. Am I missing something here? Not that I can see. I was hoping that Nolan Leake from VMware can shed some light on this. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Radeon mouse pointer bug
On Mon, 2003-02-17 at 08:11, Sean E. Russell wrote: On Sunday 16 February 2003 04:47 pm, Michel Dänzer wrote: ... 'Of course'? A crash is a bug. Does this patch help? ... Unfortunately, it doesn't. I made sure that I unloaded the radeon and agpgart kernel modules (although I didn't reboot) before starting X. I also verified that, in the XFree logfile: (II) RADEON(0): Using hardware cursor (scanline 1052) but the lag is still present. The patch is only an attempt to fix the crashes with software cursor. Are you suggesting that I might be able to fix this if I pull the head of CVS and build from those sources, Yes. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Radeon mouse pointer bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 17 February 2003 05:52 am, Michel Dänzer wrote: The patch is only an attempt to fix the crashes with software cursor. Heh. Sorry. I didn't try to crash the server. Y'know, this gets me to thinking... getting accellerated GL working on X can sometimes be a chore. If this patch silently disables GL when SWCursor is present, wouldn't this make it much more difficult for newbies to track down why they've done everything they can think of, following all of the examples and tutorials they can find, but DRM just doesn't work? IM(limited)E, there are plenty of messages saying /what/ has been done, but few saying /why/. Just voicing a stream of conciousness. In any case, I think you guys are doing a great job. Are you suggesting that I might be able to fix this if I pull the head of CVS and build from those sources, Yes. Ok, thanks. - -- ### SER Deutsch|Esperanto|Francaise|Linux|Java|Ruby|Aikido|Dirigibles ### ### http://www.germane-software.com/~ser jabber.com:ser ICQ:83578737 ### ### GPG: http://www.germane-software.com/~ser/Security/ser_public.gpg ### -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+UP0yP0KxygnleI8RAr96AJwOfIkkEno2RtNmC/5ocQjMW/XtCwCgtVPb ah+IGO2OLrkbFUWX/V642QM= =f6Pj -END PGP SIGNATURE- ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] [XFree86(TM) Bug Report] bad keyboard types in logicdn and es
On Mon, Feb 17, 2003 at 11:47:39AM -0800, Pedro D. wrote:
Regarding: bad keyboard types in logicdn and es
Email: [EMAIL PROTECTED]
XFree86 Version: 4.2.99.4
OS: linux (Madrake 9 Gentoo 1.4)
Area: xkb
Server: not server related
Description:
(**) |--Input Device Keyboard1
(**) Option XkbRules xfree86
(**) XKB: rules: xfree86
(**) Option XkbModel logicdn
(**) XKB: model: logicdn
(**) Option XkbLayout es
(**) XKB: layout: es
(==) Keyboard: CustomKeycode disabled
(**) |--Input Device Mouse1
(**) FontPath set to unix/:-1
(==) RgbPath set to /usr/X11R6/lib/X11/rgb
(==) ModulePath set to /usr/X11R6/lib/modules
(**) Option AllowMouseOpenFail
(++) using VT number 7
...
(II) Initializing built-in extension MIT-SHM
(II) Initializing built-in extension XInputExtension
(II) Initializing built-in extension XTEST
(II) Initializing built-in extension XKEYBOARD
(II) Initializing built-in extension LBX
(II) Initializing built-in extension XC-APPGROUP
(II) Initializing built-in extension SECURITY
(II) Initializing built-in extension XINERAMA
(II) Initializing built-in extension XFree86-Bigfont
(II) Initializing built-in extension RENDER
(II) Initializing built-in extension RANDR
(II) [GLX]: Initializing GLX extension
(II) Keyboard Keyboard1 handled by legacy driver
I have 2 bugs. The first is related to the driver logicdn. In the file
xkb/symbols/Inet, in the part of logicdn puts:
key FK14 { [ XF86Send ] }; // F4
key FK15 { [ XF86Undo ] }; // F5
key FK15 { [ XF86Redo ] }; // F6
key FK16 { [ XF86Print ] }; // F7
and should put:
key FK14 { [ XF86Send ] }; // F4
key FK15 { [ XF86Undo ] }; // F5
key FK16 { [ XF86Redo ] }; // F6
key FK17 { [ XF86Print ] }; // F7
but that bug is a minor problem (but it's ok to fix).
Thanks, I'll fix that.
The other bug, at least with my configuration (logitech cordless desktop navigator,
Spanish keyboard), i can't put or (the same phisical key) that correspond to
LSGT keycode. Futhermore, when i execute xev, and press that key, the program puts:
KeyPress event, serial 26, synthetic NO, window 0x381,
root 0x8d, subw 0x0, time 5002964, (165,-14), root:(175,66),
state 0x10, keycode 94 (keysym 0x0, NoSymbol), same_screen YES,
XLookupString gives 0 bytes:
(that keycode is good for xkbrules=xfree86)
i don't know how to fix this one.
I'm not sure if the best solution is to add the LSGT definition to
the pc/es map (and all others where the default keyboard has this key),
or change rules/xfree86 so that all of the inetkbds definitions are
based on pc105 instead of pc104 (the LSGT key is the only difference
between the two).
David
--
David Dawes
Release Engineer/Architect The XFree86 Project
www.XFree86.org/~dawes
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
XFree86 4.2.99.902 (4.3.0 RC2) tagged
XFree86 snapshot 4.2.99.902 (aka 4.3.0 RC2) has been tagged. This is the second release candidate for 4.3.0. The change log, which summarises what has changed since the previous snapshot, can be viewed at http://www.xfree86.org/cvs/changes.html. The source can be obtained from the XFree86 CVS repository (see http://www.xfree86.org/cvs/ for details). Binaries for a few platforms will be made available over the next day or two. They'll be at ftp://ftp.xfree86.org/pub/XFree86/snapshots/4.2.99.902/binaries/. Online documentation will soon be available at http://www.xfree86.org/4.2.99.902/. Please reports bugs here, and send bugfixes and documentation updates to [EMAIL PROTECTED] The updated 4.3 release schedule is: Code freeze (critical fixes and doc updates only)21 Feb 2003 Last submission date for doc updates 25 Feb 2003 4.3.0 tagged for release 27 Feb 2003 This schedule will stand providing no critical problems are found in the meantime. If you are aware of any serious bugs that are still present in this snapshot, please post details here. Taking some time to review and update the documentation is strongly encouraged. If you have something to add to the release notes (it should contain a summary of new features and known problems), please send it in. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: server crash on linux-mips
On Mon, 17 Feb 2003, Guido Guenther wrote: On Mon, Feb 17, 2003 at 12:10:16AM +, Alan Hourihane wrote: If you call the ShadowFBInit2 in newport_driver.c (just tag FALSE on the end of the arguments). Does that work for you ? Yes, this works. Thanks! But it's significantly slower. After switching back from the console there's nothing happenning for about 5 seconds (but I see an half updated screen), then inistantly everything is back to normal. I've seen this behavior for at least a month, on a G550, an i815 and (I think) a Radeon. I'm running xmms; if I switch to a text console, wait, switch back the xmms clock is correct but not all displays are up to date and the xmms clock stops running for up to 10 seconds until the other windows redisplay. The sound continues as normal throughout. I have only seen this on machines which I've patched to experiment with 8bit on 24bit screens, and I'd put the delay down to the large amounts of logging I'm doing. Therefore I'd assumed it was my problem, and not Xfree86. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
