[Xpert]xkb+grabbing+intl. keyboard: mode_switch does not work?
i'm running 3.3.6, and was up to now using xkb for my german keyboard. the problem i've encountered is: programs like xscreensaver, quintuple-agent etc. that are grabbing the keyboard for passphrase input cannot receive input that is generated using mode_switch+key, eg. @ (mode_switch+q). i've digged into both apps and added ugly printf debugging, and that is what i detected: there are two events generated, one for the keypress of altgr and one for q. XLookupString returns no string for the first event, which is ok as altgr/mode_switch is nonprintable and just a modifier. unfortunately, XLookupString does then return just q for the second event, which is wrong. all other x apps like xev that do not grab the keyboard work fine. everything works fine, if i switch off xkb totally. my xkb setup is absolutely plain, model pc102, layout de, variant nodeadkeys and options ctrl:nocaps. i went through the list archive, but i have not found anything that seems to be related to that problem. my question now is: is this a known problem? if so, how likely is a fix for this? regards az -- + Alexander Zangerl + [EMAIL PROTECTED] + DSA 42BD645D + (RSA 5B586291) answering machine: you've reached an imaginary number. please rotate your phone 90 degrees and try again. signature.ng
[Xpert]dual-monitor screen position help!
Hello, I am working with a dual monitor setup and am having difficulty getting the screens positioned how I would like them. Description: Screen1 is the main screen and is the larger of the two and sits to the right. Screen2 is smaller and sits off to the left. I would idealy have the setup shown below, but I haven't been able to get the setup to work yet. ___ __| | | | 1 | | 2 | | |__|___| screen2 = 1024x768 screen1 = 1280x1024 I have tried the following: -- Screen screen2 LeftOf screen1 But I get __ ___ | | | | 2 | 1 | |__| | |___| -- Screen screen2 Relative screen1 -1024 256 but X won't start , I don't think it likes the negative number. Is there any other way to do this? or another way to enter a negative number? Thanks Rich Ferguson ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: 320x204 resolution
thanks... i'll download the Xfree86 4.1.0. will let you know the results as soon as i try it. luie LdS where can I find this vesa driver and Xvesa server. LdS thanks... In XFree86 4.1.0 and later. The vesa driver is built by default, and is documented in its manual page. The Xvesa server is *not* built by default; for information about it, please see http://www.pps.jussieu.fr/~jch/software/kdrive.html and read its manual page too. __ www.edsamail.com ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: XVideo and refresh sync
Vladimir Dergachev ([EMAIL PROTECTED]): I'm talking about planning how many refreshes to show each frame. I'd be really surprised if you could say to the ATI card 'show this 2 refreshes from now'. The card won't do that, but the driver can. In this case what you do is submit a frame and a number - show this frame n-vsync interrupts from the previous one - and the driver can do the rest. Yes, for all cards which generate an interrupt every vsync then we can make an awesome API for high quality video, so long as the driver code which copies the frame is also in the kernel, since we don't want the scheduling wait of having the X driver get loaded. Having a /dev/vsync device would give the smallest amount of code in the kernel as possible, but then you need SCHED_FIFO access to protect against scheduling delays. (read: hack) You still need calls to tell you when the timebase for the refresh is though to make sure we plan ourselves out corrrectly. Regardless that kind of information is needed for TV output if you want to get field-correctness. How do the ATI cards currently export TV output capabilities when you're writing interlaced frames? The TV output API of v4l2 looks like it might be a good start. Since the requirements for TV output sync and progressive video playback sync are so similar, I'm wondering if the frame queueing API shouldn't be the same. -- Billy Biggs [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]riva 128 PCI Gamma correction broken
when using gamma correction Xserver forgots to do gamma when scrolling and few other ops making pictures broken.. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Building 4.1.0 on Linux results in segfaulting binaries
Matthew Reppert wrote: Hi, I have an AIW Radeon :) The general concensus on getting TV in/out to work for this card is that you HAVE to recompile a few things from source, one of which being X. Well, the build goes along fine, but the binaries that it makes segfault as soon as it starts loading modules. In fact, the last thing in my X log is Loading module 'bitmap'. If I just run X, I'll see Segmentation fault. on the terminal I'm on, and get booted back to bash ... I'm on kernel 2.4.12, gcc 2.95.3, GNU binutils 2.11.2 ... any ideas? Here's a copy of my host.def included as well. This is (currently) the major roadblock to getting the most out of my graphics card, and I'd like to get it to work. Very much ^^; Thanks, Matt You don't need a host.def if you haven't changed anything... Sounds like a build problem. How did you get your sources? What setup did you do? Did you do a 'make World World.log' and then a 'make install' (as root) from the 'xc' directory? (Are there any failures in the 'make World'? search for '***' in your World.log.) -- Kevin ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]xkb+grabbing+intl. keyboard: mode_switch does not work?
Alexander Zangerl [EMAIL PROTECTED] writes: i'm running 3.3.6, and was up to now using xkb for my german keyboard. the problem i've encountered is: programs like xscreensaver, quintuple-agent etc. that are grabbing the keyboard for passphrase input cannot receive input that is generated using mode_switch+key, eg. @ (mode_switch+q). i've digged into both apps and added ugly printf debugging, and that is what i detected: there are two events generated, one for the keypress of altgr and one for q. XLookupString returns no string for the first event, which is ok as altgr/mode_switch is nonprintable and just a modifier. unfortunately, XLookupString does then return just q for the second event, which is wrong. all other x apps like xev that do not grab the keyboard work fine. everything works fine, if i switch off xkb totally. my xkb setup is absolutely plain, model pc102, layout de, variant nodeadkeys and options ctrl:nocaps. i went through the list archive, but i have not found anything that seems to be related to that problem. my question now is: is this a known problem? if so, how likely is a fix for this? I've seen reports of this this problem from other people (don't remember at this point whether it was a mozilla bug report, a GTK+ bug report, a Red Hat bug report, but I remember seeing something.) I'm pretty sure this was fixed as of 4.0.x. So, you might want to try updating to something recent. Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]deadkeys
Cópia Thiago Sayao [EMAIL PROTECTED]: Oi, Deadkeys are not working on my XFree! it works on the console. See the file /usr/X11R6/lib/X11/xkb/X0-config.keyboard, it's contents should be something like: -- Rules= xfree86 Model= pc105 Layout = us_intl RepeatDelay = 699 RepeatInterval = 50 MouseKeysDelay = 160 MouseKeysInterval= 40 MouseKeysTimeToMax = 32 MouseKeysMaxSpeed= 26 MouseKeysCurve = 0 AccessXTimeout = 65535 Controls+= RepeatKeys + MouseKeysAccel Feedback+= SlowKeysPress + SlowKeysAccept + StickyKeys + LatchToLock -- Note the Model and Layout lines. These lines will override settings in XF86Config. You can remove that lines to make the XF86Config ones be used, edit the file by hand, or use xf86cfg to select the model and layout. Actually, that file will be used only for the :0 display, this needs some review for multiple keyboards and probably adding a XKB section/subsection to XF86Config. My Xfree Configuration: Section InputDevice Identifier Keyboard1 Driver Keyboard Option XkbModel pc105 Option XkbLayout us_intl EndSection My keyboard is US International. Im running Xfree4.1.0-19mdk please help! i need to use deadkeys in my language. :) ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert Paulo ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]shared and static extension libraries re(^6)-visited
Branden Robinson wrote (in a message from Thursday 18) I'd like to solicit opinions, especially from the Core Team, about the shared vs. static extension library situation. Debian just went through a bit of pain and suffering as regards SDL in our development branch, partly because we have 12 architectures to supprt for our next release. [] Also, if I've gotten any facts wrong in the above analysis, please correct me. I'm not from the XFree86 core team, so feel free to discard my message... Your analysis seem basically correct to me, to build a shared object loadable via dlopen() you need a position independant version of all code that will be loaded that way. OTOH, I'd like to say that the common habit of linking shared libraries together to allow lazy Makefiles to only list the first library of a list of dependent libraries should be discouraged, as it can create lots of problems (for instance it makes it impossible to use this Makefile on systems without shared libraries or on systems where shared libs don't have dependencies). Having remainded that, providing _pic.a versions for the libraries that are only available as static in XFree86 seems reasonable to me, to make it possible to make dlopen'able PIC module. I can even propose an implementation. How to decide which libraries should be provided as _pic.a ? Given that in my implementation the 'DoPicLib' variable will control the build of this library, I propose the following default value for each library XXX: #define DoPicLib HasSharedLibrary !SharedLibXXX And below is a proposed patch to implement it (the definition of DoPicLib in each directory is left as an exercice :-) Matthieu Index: Imake.rules === RCS file: /home/x-cvs/xc/config/cf/Imake.rules,v retrieving revision 3.101 diff -u -r3.101 Imake.rules --- Imake.rules 2001/10/02 11:44:12 3.101 +++ Imake.rules 2001/10/21 18:48:55 @@ -2550,6 +2550,20 @@ /* + * Rule to build libXXX_pic.a from PIC objects for a library + */ +#ifndef PicLibraryTarget +#definePicLibraryTarget(libname,objlist) @@\ +AllTarget(LibraryTargetNameSuffix(libname,_pic)) @@\ + @@\ +LibraryTargetNameSuffix(libname,_pic): objlist $(EXTRALIBRARYDEPS) @@\ + RemoveFile($@) @@\ + MakeLibrary($@,objlist) @@\ + RanLibrary($@) @@\ + _LinkBuildLibrary($@) +#endif /* PicLibraryTarget */ + +/* * SubdirLibraryRule - */ #ifndef SubdirLibraryRule Index: Library.tmpl === RCS file: /home/x-cvs/xc/config/cf/Library.tmpl,v retrieving revision 3.15 diff -u -r3.15 Library.tmpl --- Library.tmpl2001/08/27 17:40:55 3.15 +++ Library.tmpl2001/10/21 18:49:08 @@ -3,7 +3,7 @@ * that Imakefiles in the various library subtrees will need. * * Before including this, you must set the following boolean variables: - * DoNormalLib, DoSharedLib, DoDebugLib, DoProfileLib + * DoNormalLib, DoSharedLib, DoDebugLib, DoProfileLib, DoPicLib * * To get automatic generation of standard rules, also set the variables: * LibName, SoRev, HasSharedData, and optionally HugeLibrary and IncSubdir. @@ -21,8 +21,15 @@ XCOMM $XFree86: xc/config/cf/Library.tmpl,v 3.15 2001/08/27 17:40:55 dawes Exp $ +/* + * Some libraries may not define DoPicLib + */ +#ifndef DoPicLib +# define DoPicLib NO +#endif + #ifndef LibraryCplusplusOptions -# if DoSharedLib defined(SharedLibraryCplusplusOptions) +# if (DoSharedLib || DoPicLib) defined(SharedLibraryCplusplusOptions) # define LibraryCplusplusOptions SharedLibraryCplusplusOptions # else # define LibraryCplusplusOptions DefaultCplusplusOptions @@ -48,14 +55,14 @@ #ifndef CplusplusSource # ifndef LibraryCcCmd -# if DoSharedLib defined(SharedLibraryCcCmd) +# if (DoSharedLib || DoPicLib) defined(SharedLibraryCcCmd) # define LibraryCcCmd SharedLibraryCcCmd # else # define LibraryCcCmd CcCmd # endif # endif # ifndef LibraryCCOptions -# if DoSharedLib defined(SharedLibraryCCOptions) +# if (DoSharedLib || DoPicLib) defined(SharedLibraryCCOptions) # define LibraryCCOptions SharedLibraryCCOptions # else # define LibraryCCOptions DefaultCCOptions @@ -73,14 +80,14 @@ # endif #else # ifndef LibraryCplusplusCmd -# if DoSharedLib defined(SharedLibraryCplusplusCmd) +# if (DoSharedLib || DoPicLib) defined(SharedLibraryCplusplusCmd) # define LibraryCplusplusCmd SharedLibraryCplusplusCmd # else # define LibraryCplusplusCmd CplusplusCmd # endif # endif # ifndef LibraryCplusplusOptions -# if DoSharedLib defined(SharedLibraryCplusplusOptions) +# if (DoSharedLib ||
Re: [Xpert]Building 4.1.0 on Linux results in segfaulting binaries
Munir Nassar wrote: What compiler are you using? i am not aware of any certain compiler quirks but it is possible, gcc 2.95.3. (yanked from a make World log) Building on Linux 2.4.12 i686 [ELF] (2.4.12). Linux Distribution: Unknown libc version: 6.2.4 binutils version: 3.1 GCC version: 2.95 try a $make World World.log and check World.log for any interesting compiler warnings... Interesting? Um ... lessee. Variables possibly being used uninitialized, a few symbols declared 'static' but undefined in ttobjs.h (prolly won't hurt too much, eh?), a whole bunch of void * pointers used in arithmetic ... 6335 warnings without the void pointers, 75k void pointer warnings. Nothing here looks too bad ... the compiler never dies or anything dramatic like that. Any ideas on more specifically where to look, given that X always crashes in exactly the same place (loading module 'bitmap')? http://128.101.183.76:8080/xlogs/ Matt ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]xkb+grabbing+intl. keyboard: mode_switch does not work?
Cópia Alexander Zangerl [EMAIL PROTECTED]: Hi, i'm running 3.3.6, and was up to now using xkb for my german keyboard. the problem i've encountered is: programs like xscreensaver, quintuple-agent etc. that are grabbing the keyboard for passphrase input cannot receive input that is generated using mode_switch+key, eg. @ (mode_switch+q). i've digged into both apps and added ugly printf debugging, and that is what i detected: there are two events generated, one for the keypress of altgr and one for q. XLookupString returns no string for the first event, which is ok as altgr/mode_switch is nonprintable and just a modifier. unfortunately, XLookupString does then return just q for the second event, which is wrong. all other x apps like xev that do not grab the keyboard work fine. everything works fine, if i switch off xkb totally. my xkb setup is absolutely plain, model pc102, layout de, variant nodeadkeys and options ctrl:nocaps. i went through the list archive, but i have not found anything that seems to be related to that problem. my question now is: is this a known problem? if so, how likely is a fix for this? If the application is using only XLookupString to get keyboard input, then it will not get properly composed characters (unless there is some hack in Xlib). Implementing support for 8 bit input characters is easy, and normally can be done with a simple wrap for XLookupString, with some initialization, and then calling XmbLookupString. But the real reason I am replying is to remember people that may be working with screensavers that now there are two XF86Config options that allow users to remove keyboard/mouse/server grabs, or close the connection to the grabbing client, but there is an API for disabling the keyboard hotkeys, for use by screensavers. See the function XF86MiscSetGrabKeysState. That function will do nothing if the options AllowDeactivateGrabs and AllowClosedownGrabs are not enabled in XF86Config. regards az -- + Alexander Zangerl + [EMAIL PROTECTED] + DSA 42BD645D + (RSA 5B586291) answering machine: you've reached an imaginary number. please rotate your phone 90 degrees and try again. Paulo ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Building 4.1.0 on Linux results in segfaulting binaries
Kevin Brosius wrote: Matthew Reppert wrote: Hi, I have an AIW Radeon :) The general concensus on getting TV in/out to work for this card is that you HAVE to recompile a few things from source, one of which being X. Well, the build goes along fine, but the binaries that it makes segfault as soon as it starts loading modules. In fact, the last thing in my X log is Loading module 'bitmap'. If I just run X, I'll see Segmentation fault. on the terminal I'm on, and get booted back to bash ... I'm on kernel 2.4.12, gcc 2.95.3, GNU binutils 2.11.2 ... any ideas? Here's a copy of my host.def included as well. This is (currently) the major roadblock to getting the most out of my graphics card, and I'd like to get it to work. Very much ^^; You don't need a host.def if you haven't changed anything... Sounds like a build problem. That's what I've been thinking ... How did you get your sources? What setup did you do? Did you do a 'make World World.log' and then a 'make install' (as root) from the 'xc' directory? My sources were downloaded from this path: ftp://ftp.xfree86.org/pub/XFree86/4.1.0/source/ For setup, I've alternately tried just doing a 'make World', and putting definitions into site.def or host.def (what I posted earlier) and making World. Yes, from the xc directory, yes, as root. (Are there any failures in the 'make World'? search for '***' in your World.log.) Nothing ... it makes the binaries just fine, they're just broken ^^; Matt ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Building 4.1.0 on Linux results in segfaulting binaries
On Sun, 2001-10-21 at 21:20, Matthew Reppert wrote: Any ideas on more specifically where to look, given that X always crashes in exactly the same place (loading module 'bitmap')? What about posting the relevant parts of the X server log? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Building 4.1.0 on Linux results in segfaulting binaries
Michel Dänzer wrote: On Sun, 2001-10-21 at 21:20, Matthew Reppert wrote: What about posting the relevant parts of the X server log? Okay, this is the entire contents of XFree86.0.log. START == XFree86 Version 4.1.0 / X Window System (protocol Version 11, revision 0, vendor release 6510) Release Date: 2 June 2001 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/FAQ) Build Operating System: Linux 2.4.12 i686 [ELF] Module Loader present (==) Log file: /var/log/XFree86.0.log, Time: Sun Oct 21 14:48:09 2001 (==) Using config file: /etc/X11/XF86Config Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) ServerLayout Simple Layout (**) |--Screen Screen 1 (0) (**) | |--Monitor NEC 4FG' (**) | |--Device ATI All-in-Wonder Pro' (**) |--Input Device Mouse1 (**) |--Input Device Keyboard1 (**) Option AutoRepeat 500 30 (**) Option XkbDisable (**) XKB: disabled (==) Keyboard: CustomKeycode disabled (WW) The directory /usr/X11R6/lib/X11/fonts/truetype/ does not exist. Entry deleted from font path. (**) FontPath set to /usr/X11R6/lib/X11/fonts/local/,/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/75dpi/:unscaled,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/Speedo/,/usr/X11R6/lib/X11/fonts/75dpi/ (**) RgbPath set to /usr/X11R6/lib/X11/rgb (==) ModulePath set to /usr/X11R6/lib/modules (--) using VT number 7 (WW) Cannot open APM (II) Module ABI versions: XFree86 ANSI C Emulation: 0.1 XFree86 Video Driver: 0.4 XFree86 XInput driver : 0.2 XFree86 Server Extension : 0.1 XFree86 Font Renderer : 0.2 (II) Loader running on linux (II) LoadModule: bitmap END This is the output from the X server, just for fun ... START == XFree86 Version 4.1.0 / X Window System (protocol Version 11, revision 0, vendor release 6510) Release Date: 2 June 2001 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/FAQ) Build Operating System: Linux 2.4.12 i686 [ELF] Module Loader present (==) Log file: /var/log/XFree86.0.log, Time: Sun Oct 21 14:48:09 2001 (==) Using config file: /etc/X11/XF86Config Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) ServerLayout Simple Layout (**) |--Screen Screen 1 (0) (**) | |--Monitor NEC 4FG' (**) | |--Device ATI All-in-Wonder Pro' (**) |--Input Device Mouse1 (**) |--Input Device Keyboard1 (**) XKB: disabled (WW) The directory /usr/X11R6/lib/X11/fonts/truetype/ does not exist. Entry deleted from font path. (**) FontPath set to /usr/X11R6/lib/X11/fonts/local/,/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/75dpi/:unscaled,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/Speedo/,/usr/X11R6/lib/X11/fonts/75dpi/ (**) RgbPath set to /usr/X11R6/lib/X11/rgb (==) ModulePath set to /usr/X11R6/lib/modules (--) using VT number 7 Segmentation fault END Matt ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]riva 128 PCI Gamma correction broken
On Sun, 21 Oct 2001, Wojciech Puchar wrote: when using gamma correction Xserver forgots to do gamma when scrolling and few other ops making pictures broken.. The Riva128 doesn't support gamma correction except in 8bpp. I'll look into making it ignore the requests for the other depths. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]riva 128 PCI Gamma correction broken
On Sun, 21 Oct 2001, Wojciech Puchar wrote: when using gamma correction Xserver forgots to do gamma when scrolling and few other ops making pictures broken.. The Riva128 doesn't support gamma correction except in 8bpp. I'll look into making it ignore the requests for the other depths. but it does gamma - just not always ;) ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Random X crashes or total lockups
Hey there... ]) powered by LINUX, preemptible kernel 2.4.12-ac3 ([ Not necessarily, for some strange reason when I tell vlc to go fullscreen it causes a X lockup as well (screen goes blue), I have to kill vlc and X over ssh. No other player (mplayer, aviplay) does that on my r128. Strange things can happen :-). That reminds me of something I forgot to mention. Sometimes when I fire up XawTV, X crashes as well... yet I have only experienced this when having it use XV... so maybe... just maybe it is a bug within some XV code... but I am not sure because it is so totally random actually! :( And yes, strange things happen - but I would prefer to stop that. ;-)) -- ]) [EMAIL PROTECTED], GPG 0x51FA41C6, matthew2k on JABBER.org, ICQ# 89464954 ([ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: XVideo and refresh sync
On Sun, 21 Oct 2001 [EMAIL PROTECTED] wrote: I'm talking about planning how many refreshes to show each frame. I'd be really surprised if you could say to the ATI card 'show this 2 refreshes from now'. The card won't do that, but the driver can. In this case what you do is submit a frame and a number - show this frame n-vsync interrupts from the previous one - and the driver can do the rest. If you had kernel support you could. You could easily add a port attribute that was a hint to tell the server to display the next frame/field N vsyncs from now. The data copy could happen immediately but the display would go into effect at the desired time. You'd probably need to offload some overlay programming into the kernel and have the kernel change the overlay offset at the right time for you, but the X-server could do the rest, like setup the destination and scaling registers. The kernel merely needs to update to the new source buffer at the correct time. I don't think that's too difficult of a problem to solve. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Building 4.1.0 on Linux results in segfaulting binaries
Matthew Reppert wrote: Any ideas on more specifically where to look, given that X always crashes in exactly the same place (loading module 'bitmap')? http://128.101.183.76:8080/xlogs/ Matt What does your /etc/X11/XF86Config look like? Would you add it to this directory? Maybe you've found something that crashes the config file parser. -- Kevin ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Building 4.1.0 on Linux results in segfaulting binaries
Kevin Brosius wrote: Matthew Reppert wrote: Any ideas on more specifically where to look, given that X always crashes in exactly the same place (loading module 'bitmap')? http://128.101.183.76:8080/xlogs/ Matt What does your /etc/X11/XF86Config look like? Would you add it to this directory? Maybe you've found something that crashes the config file parser. Added. Matt ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Building 4.1.0 on Linux results in segfaulting binaries
Matthew Reppert wrote: Kevin Brosius wrote: Matthew Reppert wrote: Hi, I have an AIW Radeon :) The general concensus on getting TV in/out to work for this card is that you HAVE to recompile a few things from source, one of which being X. Well, the build goes along fine, but the binaries that it makes segfault as soon as it starts loading modules. In fact, the last thing in my X log is Loading module 'bitmap'. If I just run X, I'll see Segmentation fault. on the terminal I'm on, and get booted back to bash ... I'm on kernel 2.4.12, gcc 2.95.3, GNU binutils 2.11.2 ... any ideas? Here's a copy of my host.def included as well. This is (currently) the major roadblock to getting the most out of my graphics card, and I'd like to get it to work. Very much ^^; Hmm, another thought. What the heck is 'binutils 2.11.2'? I don't see any mention of it on ftp://ftp.kernel.org/pub/linux/devel/binutils/, which is hjl's distro location as far as I can tell. Plus it looks like 2.11 is still beta... Also, your log indicates the compile didn't detect the version, or maybe detected it incorrectly: Building on Linux 2.4.12 i686 [ELF] (2.4.12). Linux Distribution: Unknown libc version: 6.2.4 binutils version: 3.1 (Unless 3.1 really is the reporting version for binutils 2.11.x) Maybe you should try the build with an older stable version of binutils. You may also be able to add the binutils version to host.def to force it to think it has a sane version (which may or may not actually improve things.): ie: #define LinuxBinUtilsMajorVersion 26 (Read all about it in xf86site.def.) -- Kevin ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Building 4.1.0 on Linux results in segfaulting binaries
Kevin Brosius wrote: Are there modules in /usr/X11R6/lib/modules? And does the bitmap module exist there? (It's normally down a level, fonts/libbitmap.a.) Yes, it's there. Okay ... this is GNU binutils. Since I've seen people have been compiling with gcc under linux, I didn't think twice about my GNU binutils, but I'm using the most recent release of them, 2.11.2. Think that's the problem? (I should've made that clearer, prolly ... ) Matt ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Building 4.1.0 on Linux results in segfaulting binaries
On Mon, 2001-10-22 at 00:13, Matthew Reppert wrote: Okay ... this is GNU binutils. Since I've seen people have been compiling with gcc under linux, I didn't think twice about my GNU binutils, but I'm using the most recent release of them, 2.11.2. Think that's the problem? (I should've made that clearer, prolly ... ) Debian is using 2.11.92 on all architectures, and X works. So unless the version you use was particularly bad, I doubt this is the problem. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Building 4.1.0 on Linux results in segfaulting binaries
Matthew Reppert wrote: Kevin Brosius wrote: Are there modules in /usr/X11R6/lib/modules? And does the bitmap module exist there? (It's normally down a level, fonts/libbitmap.a.) Yes, it's there. Okay ... this is GNU binutils. Since I've seen people have been compiling with gcc under linux, I didn't think twice about my GNU binutils, but I'm using the most recent release of them, 2.11.2. Think that's the problem? (I should've made that clearer, prolly ... ) Matt Might be... If you built your own ld, did you use the same binutils? Or maybe it's an incompatibilty between those binutils and the XFree86 module loader (which seems likely since you can't load modules.) You could build a static server (no external modules), although that's just a workaround if you want to find out what's wrong. binutils 2.10.0.33-13 works here (that's a SuSE Linux version). And gcc 2.95.3 is considered stable, so I wouldn't worry about that. -- Kevin ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ATI Mach64 feature requests
Hmm forgot to cc: the list on this... On Sunday 21 October 2001 19:02, Mike A. Harris wrote: I'm curious as to what features of the ATI Mach64 variants that people would like to see supported or supported better in XFree86 that are either not currently supported, or are supported poorly. The first things that come to mind are: 1) DRI support 2) Xvideo support, video in/out, TV tuner, etc.. 3) ? Have I missed anything? If anyone who has worked a great deal on the ATI Mach64 driver in the past could comment their thoughts on this as well, it would be appreciated. I am researching this for someone who is interested in working on improving the drivers. Please keep in mind that this request is specifically for Mach64 family cards in particular, and not newer cards such as the r128 and Radeon families. I had the Mach64 TV _out_ feature almost reverse engineered. I have the int10 call sequence down, and I have a register trace and some of the registers decoded (I think correctly, but not 100% sure). I gave up due to lack of time but I suspect that all that remains is decoding the timing loop(s) to get the syncing working. It should be available in the gatos CVS. -- George Staikos ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: [Dri-devel] my X-Kernel question
On Mon, Oct 22, 2001 at 05:48:56AM +0100, MichaelM wrote: Would you consider it a good idea to make DRI part of the source of a kernel? Direct 3d graphics supported from the boot sequence. Hmm I thought DRI is part of the kernel? Perhaps you meant the DRM part of it. I'm really concerned about your answer. There was a whole thread on the linux-kernel mailing list about the hypothesis of the release of an X-Kernel, a kernel which would include built-in desktop support. I think it is a great idea to have a kernel implementation of Xserver. But it would have to be more modular than current XF86, and also have a highly flexible structure, so that adding new types of devices and functionality wouldn't pose problems. I think this is currently the biggest XF86's drawback. It would allow many cool things that XF86 is now struggling with (e.g. check xpert mailing list for thread about precise vsync coordination). Each device would have flags like: - can the device serve as a keyboard? - can the device serve as a pointer (mouse, joystick, touchpad, ...) - can it be used for video output? - can it grab/capture? - can it convert between colorspaces? - can it do DMA? This would allow to write drivers easily and also support combined devices (keyboard+touchpad, video+capture, ...). Second: provide data structures - keypress - mouse movement - image - font etc. and hooks for these devices to: - input data (e.g. keypress). - output data (e.g. draw pixel) - transfer data (from/to other devices, system RAM, etc). - combination of those (e.g. transfer an image from system ram and draw it) - process data internally (e.g. deinterlace?) - report status (refresh rate, vertical retrace, ...) - do something (e.g. wait for nth vsync) (think ioctl). Currently in XF86 (IMHO) for each new type of use a new standard has to be made. In this ioctl version you simply define a new value and add a function to a driver that should do it. Other drivers, or older X (as they would have something like switch (ioctl) default: return E_UNSUPPORTED;) will return an error, but nothing will crash or seize to work. Another thing is code reuse, so that several drivers can call generic functions for doing the same thing (I think the combination of transfer + output is a very good candidate for this). This is also a problem in XF86 imho. Most people answered, no, this would be ridiculous, I wouldn't put it on a server there because imho server shouldn't even have a monitor (mine don't). But for embedded and desktop, all way. But supposing you want to use a graphical interface on a box, then this kind of stuff simply DOES belong to the kernel (no I'm not an idiot and I don't have MSWindows anywhere on my computers). other said, yes, but hardware manufacturers are too unhelpful therefore this would be totally a totally unstable release. There isn't a reason why Xserver in kernel should be more unstable than user-space Xserver. Both have direct access to all memory and hardware and can lock up the machine. One thing though: There should be an interface to reload a driver that is currently in use, so that when developing it I wouldn't have to reboot everytime I recompile it. Oh and one more thing: the driver should autodetect if it is running on the same videocard as the virtual terminal stuff, so that the first card will simply open a new VT but secondary card will run independently of this VT stuff. This would finally allow a decent way to concurrently run 2 separate X sessions on the same machine using local hardware. Others said.. other various things. Ok I'll check the thread. So, what do you think? So, what do YOU think? :-) Bye, Peter Surda (Shurdeek) [EMAIL PROTECTED], ICQ 10236103, +436505122023 -- Reboot America. PGP signature
