Re: Debugging in RH8?
On Thu, 27 Feb 2003, Paul Flinders wrote: Also, we are attempting to get XFree86 debug support integrated into future FSF gdb. The major holdup is basically nobody knows who the original authors of the patches were from way back when for proper attribution and copyright assignment and all the other joys the FSF requires. I know one of the authors was Paul Flinders, and I've got an email address for him still. Does anyone else know who all worked on the XFree86 gdb patches? The only history I know of it is: The version on the XFree86 site is 4.18 or somesuch. I took that and ported it about 60% functionally to gdb 5.0, which Paul then found out about and finished off the parts that weren't working. I later ported it to gdb 5.1.1, and it's partially ported to a more recent version as well. I was the original author. I have a record of one patch from Gerd Knorr (then [EMAIL PROTECTED]) which was the PPC port, however that might just be trivial enough to not need assignment (I've included it below). Apart from yourself I don't recall any other contributions but I will have another look over my email archives. I do still check over the list to see if anyone is reporting problems but hardly anyone ever does. I'm never sure whether to interpret this as a sign that nobody uses the modified GDB or that it works fine and no-one is having problems. Thanks Paul. I'll pass this on to our tools team. As I understand it, they'll be using these patches as more or less guideance on implementing enhanced functionality into gdb that is generic rather than XFree86 specific. The FSF is a bit picky about copyright assignments and derivative works however so they've wanted to clarify this first. If all goes well, hopefully sometime in the next 6-12 months, stock FSF gdb will be able to debug a modular XFree86 X server on various different architectures. I'll be following this quite closely and working with our gdb people to test things, etc. while it is developed. Once there is something useable for other developers to test, I'll look into getting code up somewhere for people to test. It'll be nice to have gdb support for X on as many platforms and architectures as possible. Thanks again for following up. Take care, TTYL -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
libxf86config affected by LC_NUMERIC
It appears that when libxf86config writes out the config file, it is affected by the current LC_NUMERIC setting of the locale in use. Our config tool uses libxf86config and when the config file is written in any of the locales de_DE, de_DE.UTF-8, ro_RO, ro_RO.UTF-8, the following gets written to the config file for the monitor section: HorizSync30,0 - 86,0 VertRefresh 50,0 - 180,0 I've tried to reproduce this with xf86cfg as well, and am unable to reproduce it. I'm guessing that xf86cfg must change the locale to C or something prior to writing the file perhaps. I've examined the sources of the library itself, but not xf86cfg yet. Should our tool be doing this itself, or should the libxf86config library be handling it? Since the config file will be invalid if written out with LC_NUMERIC being interpreted, I believe that the library should itself be setting the locale to C prior to writing the config file perhaps. Again, I haven't investigated this very deeply, just a quick look at the code, so it's possible I'm missing something obvious. Nonetheless I thought I'd ask for input before digging into the problem deeper. Thanks in advance. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Xfree supports Hppa ?
On 28 Feb 2003, Stephane Wirtel wrote: Date: 28 Feb 2003 08:44:11 +0100 From: Stephane Wirtel [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: multipart/signed; micalg=pgp-sha1; protocol=application/pgp-signature; boundary==-X847tAdulE/AcRKns1/L Subject: Xfree supports Hppa ? Hi all, Is there a port of Xfree for HPPA 7100LC ? Because, It's unable to compile correcty Xfree86 on this CPU. The compilation is OK, but i would like to use XFree86 -configure to configure my Xfree server, I have theses errors : Elf_RelocateEntry() Unsupported relocation type 4 Elf_RelocateEntry() Unsupported relocation type 1 Elf_RelocateEntry() Unsupported relocation type 0 Elf_RelocateEntry() Unsupported relocation type 240 Elf_RelocateEntry() Unsupported relocation type 22 Elf_RelocateEntry() Unsupported relocation type 0 Elf_RelocateEntry() Unsupported relocation type 60 Elf_RelocateEntry() Unsupported relocation type 18 Elf_RelocateEntry() Unsupported relocation type 0 Elf_RelocateEntry() Unsupported relocation type 72 Elf_RelocateEntry() Unsupported relocation type 18 Elf_RelocateEntry() Unsupported relocation type 0 Elf_RelocateEntry() Unsupported relocation type 236 Elf_RelocateEntry() Unsupported relocation type 22 Elf_RelocateEntry() Unsupported relocation type 0 Elf_RelocateEntry() Unsupported relocation type 132 Elf_RelocateEntry() Unsupported relocation type 18 (EE) LoadModule: Module pcidata does not supply version information (EE) Failed to load module pcidata (invalid module, 0) Try compiling using: #define MakeDllModules YES That uses .so versions of modules instead of using the regular ELF loader mechanism. It's helpful sometimes. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
i810: X dies upon switching a text console
Hi! I've compiled entire CVS tree from 26.02 and there seem to be a problem with switching between virtual terminals in linux. I'm running SuSE 8.1 installation on a P4 box with 1Gb ram and 845G integrated graphic chip. Kernel version is 2.4.19 (shipped with suse 8.1) The tail of the FFree86.log looks like that: Error in I830WaitLpRing(), now is 147633051, start is 147631050 pgetbl_ctl: 0x3ff60001 pgetbl_err: 0x49 ipeir: 0 iphdr: 0 LP ring tail: ee10 head: 0 len: 0 start 0 eir: 0 esr: 10 emr: ff7b instdone: ffc0 instpm: 0 memmode: 0 instps: 0 hwstam: ier: 0 imr: iir: 0 space: 70120 wanted 131064 Fatal server error: lockup When reporting a problem related to a server crash, please send the full server output, not just the last messages. This can be found in the log file /var/log/XFree86.0.log. Please report problems to [EMAIL PROTECTED] The entire server log file is also atached. Regards, Max XFree86.0.log.old Description: application/trash
Re: xf86cfg: ERROR SIGSEGV caught!
On Fri, Feb 28, 2003 at 05:46:24AM -0500, Mike A. Harris wrote: On Thu, 27 Feb 2003, Stefan Dirsch wrote: No. Will be some work to extract the CVS diff for me. So you can't reproduce this problem with 4.3.0? I'll have a try with 4.3.0 now before looking deeper into this issue. I've just tried xf86cfg under 4.3 and didn't have any difficulties. One thing I did have to do was clean out ancient drivers from the modules directory -- I had several seg faults until I made sure I didn't have anything older than 4.3 installed. Strange. It only happens if libfreetype.so render module exists. I compile this against system libfreetype to get rid of some bugs in freetype2 which comes with XFree86 (some fonts can't be displayed any more which worked with freetype1 based freetype module). After loading this module every module gets a ERROR SIGSEGV caught! after loading. [...] Loading /usr/X11R6/lib/modules/fonts/libfreetype.so Module freetype: vendor=The XFree86 Project compiled for 4.3.0, module version = 2.0.2 Unloading /usr/X11R6/lib/modules/fonts/libfreetype.so Loading /usr/X11R6/lib/modules/fonts/libtype1.a Module type1: vendor=The XFree86 Project compiled for 4.3.0, module version = 1.0.2 ERROR SIGSEGV caught! Loading /usr/X11R6/lib/modules/fonts/libbitmap.a Module bitmap: vendor=The XFree86 Project compiled for 4.3.0, module version = 1.0.0 ERROR SIGSEGV caught! Maybe xf86cfg can't handle these modules. XFree86 loader can. Hmm. Perhaps this is related to the setjmp() et al. changes lately? Just a thought... No, I backed these out for testing. Must be related to xf86cfg. Maybe xf86cfg can't handle .so modules. Best regards, Stefan Public Key available Stefan Dirsch (Res. Dev.) SuSE Linux AG Tel: 0911-740530 Deutschherrnstr. 15-19 FAX: +49 911 741 77 55D-90429 Nuernberg http://www.suse.deGermany ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
SuSE has PAM
Is it possible for future releases of XFree86 to tag SuSE as using PAM as default (in config/cf/linux.cf) ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: i810: X dies upon switching a text console
Max Zaitsev [EMAIL PROTECTED] wrote: I've compiled entire CVS tree from 26.02 and there seem to be a problem with switching between virtual terminals in linux. I'm running SuSE 8.1 I'm quite fine over here with 4.3.0 CVS on SuSE-8.1. I set #define NothingOutsideProjectRoot YES in 'site.def' and installed the whole thing over the existing /usr/X11R6/ directory. I also patched the DRM kernel sources according to the stuff in 'os-support/'. I just forgot to activate PAM (see other posting), Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xf86cfg: ERROR SIGSEGV caught!
On Fri, Feb 28, 2003 at 05:46:24AM -0500, Mike A. Harris wrote: On Thu, 27 Feb 2003, Stefan Dirsch wrote: No. Will be some work to extract the CVS diff for me. So you can't reproduce this problem with 4.3.0? I'll have a try with 4.3.0 now before looking deeper into this issue. I've just tried xf86cfg under 4.3 and didn't have any difficulties. One thing I did have to do was clean out ancient drivers from the modules directory -- I had several seg faults until I made sure I didn't have anything older than 4.3 installed. Strange. It only happens if libfreetype.so render module exists. I compile this against system libfreetype to get rid of some bugs in freetype2 which comes with XFree86 (some fonts can't be displayed any more which worked with freetype1 based freetype module). After loading this module every module gets a ERROR SIGSEGV caught! after loading. [...] Loading /usr/X11R6/lib/modules/fonts/libfreetype.so Module freetype: vendor=The XFree86 Project compiled for 4.3.0, module version = 2.0.2 Unloading /usr/X11R6/lib/modules/fonts/libfreetype.so Loading /usr/X11R6/lib/modules/fonts/libtype1.a Module type1: vendor=The XFree86 Project compiled for 4.3.0, module version = 1.0.2 ERROR SIGSEGV caught! Loading /usr/X11R6/lib/modules/fonts/libbitmap.a Module bitmap: vendor=The XFree86 Project compiled for 4.3.0, module version = 1.0.0 ERROR SIGSEGV caught! Maybe xf86cfg can't handle these modules. XFree86 loader can. Hmm. Perhaps this is related to the setjmp() et al. changes lately? Just a thought... Mmm, Mike - did you actually read this thread before making this comment ? Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Xfree supports Hppa ?
Where have i to define this #define ? :d On Fri, 2003-02-28 at 11:44, Mike A. Harris wrote: On 28 Feb 2003, Stephane Wirtel wrote: Date: 28 Feb 2003 08:44:11 +0100 From: Stephane Wirtel [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: multipart/signed; micalg=pgp-sha1; protocol=application/pgp-signature; boundary==-X847tAdulE/AcRKns1/L Subject: Xfree supports Hppa ? Hi all, Is there a port of Xfree for HPPA 7100LC ? Because, It's unable to compile correcty Xfree86 on this CPU. The compilation is OK, but i would like to use XFree86 -configure to configure my Xfree server, I have theses errors : Elf_RelocateEntry() Unsupported relocation type 4 Elf_RelocateEntry() Unsupported relocation type 1 Elf_RelocateEntry() Unsupported relocation type 0 Elf_RelocateEntry() Unsupported relocation type 240 Elf_RelocateEntry() Unsupported relocation type 22 Elf_RelocateEntry() Unsupported relocation type 0 Elf_RelocateEntry() Unsupported relocation type 60 Elf_RelocateEntry() Unsupported relocation type 18 Elf_RelocateEntry() Unsupported relocation type 0 Elf_RelocateEntry() Unsupported relocation type 72 Elf_RelocateEntry() Unsupported relocation type 18 Elf_RelocateEntry() Unsupported relocation type 0 Elf_RelocateEntry() Unsupported relocation type 236 Elf_RelocateEntry() Unsupported relocation type 22 Elf_RelocateEntry() Unsupported relocation type 0 Elf_RelocateEntry() Unsupported relocation type 132 Elf_RelocateEntry() Unsupported relocation type 18 (EE) LoadModule: Module pcidata does not supply version information (EE) Failed to load module pcidata (invalid module, 0) Try compiling using: #define MakeDllModulesYES That uses .so versions of modules instead of using the regular ELF loader mechanism. It's helpful sometimes. -- Stephane Wirtel [EMAIL PROTECTED] WebSite : http://www.linux-mons.be GPG ID : 1024D/C9C16DA7 Fingerprint : 5331 0B5B 21F0 0363 EACD B73E 3D11 E5BC C9C1 6DA7 signature.asc Description: This is a digitally signed message part
Re: Xfree supports Hppa ?
On 28 Feb 2003, Stephane Wirtel wrote: Date: 28 Feb 2003 14:38:27 +0100 From: Stephane Wirtel [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Content-Type: multipart/signed; micalg=pgp-sha1; protocol=application/pgp-signature; boundary==-TPMUMeIjclXekwOxLjVG Subject: Re: Xfree supports Hppa ? Where have i to define this #define ? :d host.def -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Misleading Makefile samples for Linux ?
I find the Makefile samples in: xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/ a bit misleading. For instance the mga_irq.c, r128_irq.c and radeon_irq.c don't get included (they live in os-support/shared/drm/kernel/). Is this the intended behaviour ? Unless I link the 'irq' stuff into the kernel modules, they fail to load because of missing references, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Misleading Makefile samples for Linux ?
On Fre, 2003-02-28 at 15:51, Michel Dänzer wrote: On Fre, 2003-02-28 at 15:41, Martin Spott wrote: I find the Makefile samples in: xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/ a bit misleading. For instance the mga_irq.c, r128_irq.c and radeon_irq.c don't get included (they live in os-support/shared/drm/kernel/). Is this the intended behaviour ? Unless I link the 'irq' stuff into the kernel modules, they fail to load because of missing references, Are you using Makefile.kernel instead of Makefile.linux? I don't know what the latter is for, Sorry, I mean the former of course. -- 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: xf86cfg: ERROR SIGSEGV caught!
On Fri, 28 Feb 2003, Alan Hourihane wrote: From: Alan Hourihane [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Subject: Re: xf86cfg: ERROR SIGSEGV caught! Loading /usr/X11R6/lib/modules/fonts/libfreetype.so Module freetype: vendor=The XFree86 Project compiled for 4.3.0, module version = 2.0.2 Unloading /usr/X11R6/lib/modules/fonts/libfreetype.so Loading /usr/X11R6/lib/modules/fonts/libtype1.a Module type1: vendor=The XFree86 Project compiled for 4.3.0, module version = 1.0.2 ERROR SIGSEGV caught! Loading /usr/X11R6/lib/modules/fonts/libbitmap.a Module bitmap: vendor=The XFree86 Project compiled for 4.3.0, module version = 1.0.0 ERROR SIGSEGV caught! Maybe xf86cfg can't handle these modules. XFree86 loader can. Hmm. Perhaps this is related to the setjmp() et al. changes lately? Just a thought... Mmm, Mike - did you actually read this thread before making this comment ? No I did not. I read the message I responded to, which is the only message aside from the one before it in my mail folder. I responded based on that. After your response and reading list archives, it seems that my comment was right on the money too. Was there a particular reason to be rude about my attempt to help, or am I missing something? -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Input driver communication with calibration application?
Driver communication in the XINPUT protocol is very incomplete, and even less complete in XFree86. The only way to do it now within the XINPUT protocol is to mis-use an existing Feedback control. But, most feedback controls are not yet implemented in 4.x. THe only way I have found to work is to encapsulate data in XChangeDeviceControl messages. For example, if valuator 0 is zero, then valuator 1 contains data to append to an internal data buffer, which could be a plain text string ending in NUL. You could then parse that string for simple parameter/value] pairs. Joe Krahn Burt Bicksler wrote: Hi, I'm working with a touch screen driver in XFree86 4.0.x.. and I have need to communicate with the touch screen driver from an X application that is used for calibration. Specifically I want to be able to turn off existing calibration, and then give the driver updated configuration after the user is finished. What is the best way to perform this type of communication with an XInput driver from an X application? Thanks, Burt ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: i810: X dies upon switching to a text console
I'm quite fine over here with 4.3.0 CVS on SuSE-8.1. I set #define NothingOutsideProjectRoot YES I'm recompiling X now to see if this helps in 'site.def' and installed the whole thing over the existing /usr/X11R6/ directory. I did the same. Actually, I had another problem, reasons for which I have not checked yet: after replacing X xdm refuses to start, but startx works fine. I also patched the DRM kernel sources according to the stuff in 'os-support/'. I did not do that. Can those crashes occur because of misunderstandings between X's i810 driver and kernel's framebuffer driver? I just forgot to activate PAM (see other posting), forgive my illiterance, but what is PAM? Regards, Max ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
NetMousePS/2 problem - Netscroll Optical
Hi, I have a NetScroll Optical PS/2 mouse. Since I upgraded from 4.2.1 to some 4.2.99 XFree version, the mouse behaves very strange: it moves very slow and whenever I lift it from it's surface it jumps to the bottom left corner (thus being unusable). This is only the case when using the NetMousePS/2 protocol, switching to auto (imps/2 is detected) fixes the problem (but then I can't use my extra mouse buttons). Now I'm using XFree86-4.3-1mdk and the problem is still there. When switching back to a backupped version of my Mandrake 9.0 system (with older XFree-86-4.2.0), it works fine. some extra info: I disabled gpm The relavant part in XF86Config-4 Identifier Mouse1 Driver mouse Option ProtocolNetMousePS/2 Option Device /dev/mouse Option Buttons7 Option ZAxisMapping 6 7 (disabling the last 2 lines doesn't solve the problem) NOT WORKING log output (XFree 4.3) (II) Keyboard Keyboard1 handled by legacy driver (**) Option Protocol NetMousePS/2 (**) Mouse1: Protocol: NetMousePS/2 (**) Option CorePointer (**) Mouse1: Core Pointer (**) Option Device /dev/mouse (**) Option Buttons 7 (**) Mouse1: Emulate3Buttons, Emulate3Timeout: 50 (**) Option ZAxisMapping 6 7 (**) Mouse1: ZAxisMapping: buttons 6 and 7 (**) Mouse1: Buttons: 7 (II) XINPUT: Adding extended input device Mouse1 (type: MOUSE) (II) Mouse1: ps2EnableDataReporting: succeeded (II) 3rd Button detected: disabling emulate3Button WORKING (XFree 4.2.0) (II) Initializing built-in extension RENDER (**) Option Protocol NetMousePS/2 (**) Mouse1: Protocol: NetMousePS/2 (**) Option CorePointer (**) Mouse1: Core Pointer (**) Option Device /dev/mouse (**) Option Buttons 7 (**) Option ZAxisMapping 6 7 (**) Mouse1: ZAxisMapping: buttons 6 and 7 (**) Mouse1: Buttons: 7 (II) Keyboard Keyboard1 handled by legacy driver (II) XINPUT: Adding extended input device Mouse1 (type: MOUSE) greetings, Dominique De Munck ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple video consoles
On Thu, Feb 27, 2003 at 10:11:34AM +0100, Sven Luther wrote: BTW, Dawes, what are the plans for post 4.3.0 XFree86 ? This kind of thing would most assuredly go into the thinking about 5.x, but some of the stuff here, and about the dual-head/one FB (which would allow DRI on dual head cards) could also be implemented in the current setting. We definitely want to discuss the dual-seat possibilities in the context of 5.0. I agree that dual-head/one FB (single seat) can be handled in the current 4.x environment. Several 3rd party drivers already handle this in one way or another. I did some configuration and infrastructure related work on this for a project that got cut. One of the things this handled was the configuration for mutiple monitor viewports being attached to a single screen. Now that 4.3.0 is out, I'd like to go back and finish that off, and modify one of the existing dual CRTC drivers to make use of it. 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: xf86cfg: ERROR SIGSEGV caught!
On Thu, Feb 27, 2003 at 09:40:00PM +0100, Stefan Dirsch wrote: On Thu, Feb 27, 2003 at 09:51:15AM -0800, Keith Packard wrote: Around 16 o'clock on Feb 27, Stefan Dirsch wrote: No. Will be some work to extract the CVS diff for me. So you can't reproduce this problem with 4.3.0? I'll have a try with 4.3.0 now before looking deeper into this issue. I've just tried xf86cfg under 4.3 and didn't have any difficulties. One thing I did have to do was clean out ancient drivers from the modules directory -- I had several seg faults until I made sure I didn't have anything older than 4.3 installed. Strange. It only happens if libfreetype.so render module exists. I You can potentially run into all sorts of problems using .so modules. If you see the problem with a .a version, then we have a real problem to follow up. 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: Misleading Makefile samples for Linux ?
Michel D?nzer [EMAIL PROTECTED] wrote: Are you using Makefile.kernel instead of Makefile.linux? I don't know what the latter is for, I asked on dri-devel a while ago but didn't get any replies. Makefile.kernel is supposed to be a sample for how the Makefile in the kernel tree should look like. It is really quite similar to the one in drivers/char/drm/ of the kernel tree, but it misses relevant entries - that's why I'm posting. I think Makefile.linux is meant for building the kernel modules outside the kernel tree (inside the XFree86/DRI tree ?)- but I never tried that, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 4.3.0 questions
On Thu, Feb 27, 2003 at 06:06:27PM -0800, Kendall Bennett wrote: Hi Guys, I noticed this in the XFree86 4.3.0 release notes: We have plans to make the configuration file optional in a future release. The XFree86 server is close to being able to automatically determine a complete base configuration for most popular hardware configurations. How does this affect installable modules such as our drivers (soon to be released) that can support multiple chipsets that are already supported by existing driver modules? The same would go for NVIDIA, ATI and Matrox binary only drivers - how would they be handled? What we're doing here will still handle 3rd party modules. At a minimum there will be an editable mapping between hardware and driver modules. That mapping won't be hard-coded into the XFree86 server (although some generic fallback might). In your case, where one driver handles everything, the mapping would be trivial. In the 4.x time frame, the XF86Config file won't disappear (just not be required), and it (or some equivalent) will always be needed to store configuration preference information. 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: Multiple video consoles
On Fri, Feb 28, 2003 at 11:59:48AM -0500, David Dawes wrote: On Thu, Feb 27, 2003 at 10:11:34AM +0100, Sven Luther wrote: BTW, Dawes, what are the plans for post 4.3.0 XFree86 ? This kind of thing would most assuredly go into the thinking about 5.x, but some of the stuff here, and about the dual-head/one FB (which would allow DRI on dual head cards) could also be implemented in the current setting. We definitely want to discuss the dual-seat possibilities in the context of 5.0. I agree that dual-head/one FB (single seat) can be handled in the current 4.x environment. Several 3rd party drivers already handle this in one way or another. I did some configuration and infrastructure related work on this for a project that got cut. One of the things this handled was the configuration for mutiple monitor viewports being attached to a single screen. Now that 4.3.0 is out, I'd like to go back and finish that off, and modify one of the existing dual CRTC drivers to make use of it. There was some discution about this in the DRI mailing list, and i am also currently writing a driver which would need this kind of thing. I guess that you can tell the driver via the device section that it is to share the Framebuffer between monitors and that you can then use the viewport on the display subsection to set the viewport to wherever you want. Now, if you want one of the viewports to do some scaling too, either because your LCD monitor is fixed size, and a program want to run in another size, or for having one viewport displaying a zoomed part of the other or whatever. I think this is not currently possible, but i may be wrong. Also it would be nice if we could follow a window with a viewport, and adjust the zoom factor accordyingly. BTW, is it normal that SDL games requesting 640x480 try to set it even if i did only specify 1024x768 in the monitor modes, and thus give blank screens ? I observed this both in my being worked on driver and in the vesa driver (using frozen-bubbles and solarwolf in fullscreen mode). Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: i810: X dies upon switching to a text console
Max Zaitsev [EMAIL PROTECTED] wrote: I'm quite fine over here with 4.3.0 CVS on SuSE-8.1. I set #define NothingOutsideProjectRoot YES I'm recompiling X now to see if this helps I hope you saved some sort of logfile to see what's already been overwritten by your former 'make install' ;-) I did the same. Actually, I had another problem, reasons for which I have not checked yet: after replacing X xdm refuses to start, but startx works fine. Maybe 'xdm' expects to find its configuration files somewhere else. You might want to have a look at 'xdm-config' - under certain circumstances 'xdm' decides not to start after reading that file. I also patched the DRM kernel sources according to the stuff in 'os-support/'. I did not do that. Can those crashes occur because of misunderstandings between X's i810 driver and kernel's framebuffer driver? You have to ask anyone who really has a clue I just forgot to activate PAM (see other posting), forgive my illiterance, but what is PAM? Pluggable Authentication Modules - I use this to authenticate against an LDAP server on the local network, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Misleading Makefile samples for Linux ?
On Fri, Feb 28, 2003 at 12:31:53PM -0500, David Dawes wrote: On Fri, Feb 28, 2003 at 03:51:04PM +0100, Michel Dänzer wrote: On Fre, 2003-02-28 at 15:41, Martin Spott wrote: I find the Makefile samples in: xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/ a bit misleading. For instance the mga_irq.c, r128_irq.c and radeon_irq.c don't get included (they live in os-support/shared/drm/kernel/). Is this the intended behaviour ? Unless I link the 'irq' stuff into the kernel modules, they fail to load because of missing references, Are you using Makefile.kernel instead of Makefile.linux? I don't know what the latter is for, I asked on dri-devel a while ago but didn't get any replies. Makefile.kernel was supposed to the a Makefile suitable for dropping into the kernel source tree's drivers/char/drm directory. It's never used directly from the XFree86 source tree, and that's probably why it is out of date. I don't know if there's any point keeping it around or not. It is nice to have when you just copy the X drm subtree to the kernel you are building, so that the drm drivers can be built in one go, or even builtin the kernel. They need to be uptodate though for that to work, or that we have one for various kernel versions, or at least state for what range of kernels they will work. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Monitor section in config file?
Andrew C Aitchison [EMAIL PROTECTED] wrote: Also where do I find the docs on the XF86Config file format. I need to read up some more on this. man XF86Config Right, I found that about 10 minutes after I posted ;-) Correct in all cases, although when X -configure creates those values from DDC it currently uses a size derived from the monitor size in cm, rather than the size in millimetres of any particular mode. Ok. X -configure comments these values out because many apps used to get confused by having precise dpi values and displayed silly fonts. I think that at one time a 85x90 dpi screen would make Netscape use 75x100dpi fonts. I note that Netscape 7 allows you to calibrate the horizontal screen pitch, but not the vertical pitch. So you are saying that should leave this section of the config file commented out for better compatibility? I have commented it out for now anyway, as I haven't added the code in the installer to grab the values from the EDID yet. I can just as easily leave it off (Red Hat 8.0 seems ot get it directly from DDC when it is not in the config file anyway). Regards, --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 4.3.0 questions
David Dawes [EMAIL PROTECTED] wrote: How does this affect installable modules such as our drivers (soon to be released) that can support multiple chipsets that are already supported by existing driver modules? The same would go for NVIDIA, ATI and Matrox binary only drivers - how would they be handled? What we're doing here will still handle 3rd party modules. At a minimum there will be an editable mapping between hardware and driver modules. That mapping won't be hard-coded into the XFree86 server (although some generic fallback might). In your case, where one driver handles everything, the mapping would be trivial. Sounds good. So I assume this will probably be just a PCI-driver type mapping for PCI/AGP devices (and something else for older non-PCI stuff)? In the 4.x time frame, the XF86Config file won't disappear (just not be required), and it (or some equivalent) will always be needed to store configuration preference information. Sounds good to me. The XF86Config file has always been a bit of a nightmare for non-techies to edit anyway ;-) Regards, --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Mouse Daemon for Linux/FreeBSD?
Hi Guys, I have to revist the mouse handling code in our MGL graphics library (runs in a console mode without X11) as it has been busted on Red Hat 7.3 and later machines. One of the things that has always bugged me about Linux is that there is no centralised mouse daemon in the system. GPM is closed, but it is not used by many apps (we used GPM but when that changes that is what broke it for us). So I am wondering what sort of interest there would be in a high quality mouse daemon for Linux that could handle all of the mouse communications for Linux programs. The idea would be that there would be a single mouse daemon in the system that runs in user space that auto-detects the installed mouse and provides event translation for all apps in the system, including XFree86. My plan would be to start with the XFree86 mouse handling code and essentially figure out a way to make it into a separate daemon that can be shared. If I do this, is there any interest in using it? If not I guess I will just port the XFree86 mouse code to our MGL library, but that kind of sucks because I will have to keep on top of changes to the XFree86 code to maintain our mouse handling modules. Also the more I think about it perhaps the daemon should handle both mouse and keyboard event drive input (ie: an input daemon) so all this stuff is centralised for event driven GUI environments)? Regards, --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Mouse Daemon for Linux/FreeBSD?
Charl P. Botha [EMAIL PROTECTED] wrote: On Fri, Feb 28, 2003 at 10:54:17AM -0800, Kendall Bennett wrote: So I am wondering what sort of interest there would be in a high quality mouse daemon for Linux that could handle all of the mouse communications for Linux programs. The idea would be that there would be a single mouse daemon in the system that runs in user space that auto-detects the installed mouse and provides event translation for all apps in the system, including XFree86. Before you start churning out reams of code, please have a look at the new Linux kernel 2.5 input layer. Drivers are at kernel level and are presented to userland via a generic event interface. Interesting. So that means the 2.5 input layer drivers will in effect be providing a new generic interface to all Linux apps? Very nice! Do you have a good place where I can find documentation on this, or should I just grab the latest 2.5 kernel source code and look at the source itself? Is this going to be used by XFree86 any time soon? The catch of course is that we need some backwards compatibility. Perhaps a good solution would be one designed to utilise the 2.5 kernel input layer interfaces if they are present, but to use old XFree86 style code if they are not (ie: implement a user land daemon that will abstract the new 2.5 kernel interface code and make it backwards comaptible with earlier kernels). What do you think? Regards, --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple video consoles
On Fri, Feb 28, 2003 at 02:06:35PM -0500, David Dawes wrote: On Fri, Feb 28, 2003 at 06:27:20PM +0100, Sven Luther wrote: On Fri, Feb 28, 2003 at 11:59:48AM -0500, David Dawes wrote: On Thu, Feb 27, 2003 at 10:11:34AM +0100, Sven Luther wrote: BTW, Dawes, what are the plans for post 4.3.0 XFree86 ? This kind of thing would most assuredly go into the thinking about 5.x, but some of the stuff here, and about the dual-head/one FB (which would allow DRI on dual head cards) could also be implemented in the current setting. We definitely want to discuss the dual-seat possibilities in the context of 5.0. I agree that dual-head/one FB (single seat) can be handled in the current 4.x environment. Several 3rd party drivers already handle this in one way or another. I did some configuration and infrastructure related work on this for a project that got cut. One of the things this handled was the configuration for mutiple monitor viewports being attached to a single screen. Now that 4.3.0 is out, I'd like to go back and finish that off, and modify one of the existing dual CRTC drivers to make use of it. There was some discution about this in the DRI mailing list, and i am also currently writing a driver which would need this kind of thing. I guess that you can tell the driver via the device section that it is to share the Framebuffer between monitors and that you can then use the viewport on the display subsection to set the viewport to wherever you want. The static configuration handles associating multiple monitors, sets of modes, initial viewport positioning, etc with a single Device/Screen. Are you speaking about the current 4.3.0 or the stuff you are working on ? Now, if you want one of the viewports to do some scaling too, either because your LCD monitor is fixed size, and a program want to run in another size, or for having one viewport displaying a zoomed part of the other or whatever. I think this is not currently possible, but i may be wrong. Also it would be nice if we could follow a window with a viewport, and adjust the zoom factor accordyingly. Mode switching would work for multiple monitors, and they could be made to switch independently. Handling this switching, and providing useful run-time control over the origin of the viewports is the next step after the static configuration. It could be handled with some combination of hot keys, pointer scrolling, and/or a control client. Are you also interested in doing scaling other than what you get for free by having one monitor display at a lower resolution? Well, i am not sure i follow you completely here, but my interrest in scaling is : o having one monitor display the same framebuffer area as the other, but in another resolution. Like when your laptop's LCD screen can only display 1024x768 but you have to do a presentation on a 800x600 video projector. You sent the framebuffer to be 800x600 to have maximum quality on the video projector, and scale it to 1024x768 on the mirrored display of your LCD screen. o displaying lower video modes than what the LCD screen can display (or bigger modes also). These would be static scalings, and could be set by specifying for the viewport, not only the x/y corner like it is done right now, but also the source height and width, the scaling would then be set to the ratio between the height/width of the destination over the source. Keep in mind LCD monitors can only do fixed resolution mostly and will become more and more predominant. Then there is dynamic viewports, similar to what matrox does for windows zooming on their windows drivers (i have not seen this personnally though). You could designate a window, and have it be used for the viewport of a second head. The second viewport would follow the window and scale it apropriatedly, including if the window is moved around or resized. And we would do dual head, not like now with splitting the framebuffer into two zones, one for each head, but by sharing the same framebuffer between both screens, this would give free dual head DRI also, if the 3D engine supports such big displays. Overlay and cursor still would need to be done separatedly. BTW, is it normal that SDL games requesting 640x480 try to set it even if i did only specify 1024x768 in the monitor modes, and thus give blank screens ? I observed this both in my being worked on driver and in the vesa driver (using frozen-bubbles and solarwolf in fullscreen mode). I've seen games that just put a 640x480 window in one corner of the 1024x768 screen when there's no 640x480 monitor mode available. Well, apparently SDL will default to the next higher supported mode, but apparently something is broken there. But still, X should not try setting a mode not declared in the XF86Config file, whatever the app asks. Friendly, Sven Luther ___ Devel mailing list [EMAIL
Re: Mouse Daemon for Linux/FreeBSD?
I believe Zephaniah E. Hull was doing some work for getting xfree86 to work dynamically with the 2.5 input layer. I think it was called evdev. I can't seem to find the link to his site at the moment though. Alex --- Charl P. Botha [EMAIL PROTECTED] wrote: On Fri, Feb 28, 2003 at 10:54:17AM -0800, Kendall Bennett wrote: So I am wondering what sort of interest there would be in a high quality mouse daemon for Linux that could handle all of the mouse communications for Linux programs. The idea would be that there would be a single mouse daemon in the system that runs in user space that auto-detects the installed mouse and provides event translation for all apps in the system, including XFree86. Before you start churning out reams of code, please have a look at the new Linux kernel 2.5 input layer. Drivers are at kernel level and are presented to userland via a generic event interface. -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xf86cfg: ERROR SIGSEGV caught!
On Fri, Feb 28, 2003 at 11:06:49 -0500, Mike A. Harris wrote: On Fri, 28 Feb 2003, Alan Hourihane wrote: From: Alan Hourihane [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Subject: Re: xf86cfg: ERROR SIGSEGV caught! Loading /usr/X11R6/lib/modules/fonts/libfreetype.so Module freetype: vendor=The XFree86 Project compiled for 4.3.0, module version = 2.0.2 Unloading /usr/X11R6/lib/modules/fonts/libfreetype.so Loading /usr/X11R6/lib/modules/fonts/libtype1.a Module type1: vendor=The XFree86 Project compiled for 4.3.0, module version = 1.0.2 ERROR SIGSEGV caught! Loading /usr/X11R6/lib/modules/fonts/libbitmap.a Module bitmap: vendor=The XFree86 Project compiled for 4.3.0, module version = 1.0.0 ERROR SIGSEGV caught! Maybe xf86cfg can't handle these modules. XFree86 loader can. Hmm. Perhaps this is related to the setjmp() et al. changes lately? Just a thought... Mmm, Mike - did you actually read this thread before making this comment ? No I did not. I read the message I responded to, which is the only message aside from the one before it in my mail folder. I responded based on that. After your response and reading list archives, it seems that my comment was right on the money too. Referring to Stefan's original email you'd have seen he already made the comment about setjmp(). Was there a particular reason to be rude about my attempt to help, or am I missing something? You were just re-stating something that the original poster had already mentioned, and David's followup even asked for Stefan to try reversing the patch anyway to see if the problem resolved itself. Nothing rude about it. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Mouse Daemon for Linux/FreeBSD?
Jeff Garzik [EMAIL PROTECTED] wrote: On Fri, Feb 28, 2003 at 12:26:23PM -0800, Kendall Bennett wrote: Jeff Garzik [EMAIL PROTECTED] wrote: Note that CONFIG_INPUT (the new input layer) exists in 2.4.x kernels as well... so you can test right now. It's just that 2.5.x (and 2.6.0 when released) has made the new input layer the default. What do you mean they were made the default? Do you have to reconfigure the kernel in 2.4 to make use of them, or will they work out of the box with existing 2.4 kernels? Depending on your kernel configuration, you either need to load alternative drivers, or, reconfigure and recompile your kernel. CONFIG_INPUT is the config option you want. Ok, that is what I was afraid of. We need something that will work 'out of the box', so it sounds like that won't happen until 2.6 is released (or code is backported and enabled in 2.4 kernels). Regards, --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Mouse Daemon for Linux/FreeBSD?
On Fri, Feb 28, 2003 at 12:56:22PM -0800, Kendall Bennett wrote: Jeff Garzik [EMAIL PROTECTED] wrote: On Fri, Feb 28, 2003 at 12:26:23PM -0800, Kendall Bennett wrote: Jeff Garzik [EMAIL PROTECTED] wrote: Note that CONFIG_INPUT (the new input layer) exists in 2.4.x kernels as well... so you can test right now. It's just that 2.5.x (and 2.6.0 when released) has made the new input layer the default. What do you mean they were made the default? Do you have to reconfigure the kernel in 2.4 to make use of them, or will they work out of the box with existing 2.4 kernels? Depending on your kernel configuration, you either need to load alternative drivers, or, reconfigure and recompile your kernel. CONFIG_INPUT is the config option you want. Ok, that is what I was afraid of. We need something that will work 'out of the box', so it sounds like that won't happen until 2.6 is released (or code is backported and enabled in 2.4 kernels). Like I said, it depends on your kernel configuration. Red Hat ships with the new input layer built. Jeff ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple video consoles
On Fri, Feb 28, 2003 at 09:04:06PM +0100, Sven Luther wrote: On Fri, Feb 28, 2003 at 02:06:35PM -0500, David Dawes wrote: On Fri, Feb 28, 2003 at 06:27:20PM +0100, Sven Luther wrote: On Fri, Feb 28, 2003 at 11:59:48AM -0500, David Dawes wrote: On Thu, Feb 27, 2003 at 10:11:34AM +0100, Sven Luther wrote: BTW, Dawes, what are the plans for post 4.3.0 XFree86 ? This kind of thing would most assuredly go into the thinking about 5.x, but some of the stuff here, and about the dual-head/one FB (which would allow DRI on dual head cards) could also be implemented in the current setting. We definitely want to discuss the dual-seat possibilities in the context of 5.0. I agree that dual-head/one FB (single seat) can be handled in the current 4.x environment. Several 3rd party drivers already handle this in one way or another. I did some configuration and infrastructure related work on this for a project that got cut. One of the things this handled was the configuration for mutiple monitor viewports being attached to a single screen. Now that 4.3.0 is out, I'd like to go back and finish that off, and modify one of the existing dual CRTC drivers to make use of it. There was some discution about this in the DRI mailing list, and i am also currently writing a driver which would need this kind of thing. I guess that you can tell the driver via the device section that it is to share the Framebuffer between monitors and that you can then use the viewport on the display subsection to set the viewport to wherever you want. The static configuration handles associating multiple monitors, sets of modes, initial viewport positioning, etc with a single Device/Screen. Are you speaking about the current 4.3.0 or the stuff you are working on ? What I was working on. Now, if you want one of the viewports to do some scaling too, either because your LCD monitor is fixed size, and a program want to run in another size, or for having one viewport displaying a zoomed part of the other or whatever. I think this is not currently possible, but i may be wrong. Also it would be nice if we could follow a window with a viewport, and adjust the zoom factor accordyingly. Mode switching would work for multiple monitors, and they could be made to switch independently. Handling this switching, and providing useful run-time control over the origin of the viewports is the next step after the static configuration. It could be handled with some combination of hot keys, pointer scrolling, and/or a control client. Are you also interested in doing scaling other than what you get for free by having one monitor display at a lower resolution? Well, i am not sure i follow you completely here, but my interrest in scaling is : o having one monitor display the same framebuffer area as the other, but in another resolution. Like when your laptop's LCD screen can only display 1024x768 but you have to do a presentation on a 800x600 video projector. You sent the framebuffer to be 800x600 to have maximum quality on the video projector, and scale it to 1024x768 on the mirrored display of your LCD screen. o displaying lower video modes than what the LCD screen can display (or bigger modes also). The type of scaling that comes for free is when your LCD displays 1024x768 and the video projector displays 800x600, but that 800x600 is just a 800x600 pixel subset of the full 1024x768 desktop. Other forms of scaling are either handled by a hardware scaler (that may or may not be visible to the XFree86 server and user), or by having something in XFree86 that keeps a second copy of the image that is scaled in software. A lot of chipsets that drive LCD displays do transparent scaling where the user and XFree86 server see a 800x600 mode, and the graphic hardware scales that to the 1024x768 physical LCD screen. These would be static scalings, and could be set by specifying for the viewport, not only the x/y corner like it is done right now, but also the source height and width, the scaling would then be set to the ratio between the height/width of the destination over the source. Keep in mind LCD monitors can only do fixed resolution mostly and will become more and more predominant. Most of the current LCD monitors that I've seen can do built-in scaling so that they can display non-native resolutions transparently to the user. Then there is dynamic viewports, similar to what matrox does for windows zooming on their windows drivers (i have not seen this personnally though). You could designate a window, and have it be used for the viewport of a second head. The second viewport would follow the window and scale it apropriatedly, including if the window is moved around or resized. I don't know how the Matrox driver works specifically, but if it allows arbitrary scaling it may use hardware scaling for the second viewport (like XVideo usually uses) to achieve this efficiently. I
Re: Mouse Daemon for Linux/FreeBSD?
Jeff Garzik [EMAIL PROTECTED] wrote: Ok, that is what I was afraid of. We need something that will work 'out of the box', so it sounds like that won't happen until 2.6 is released (or code is backported and enabled in 2.4 kernels). Like I said, it depends on your kernel configuration. Red Hat ships with the new input layer built. By built you mean it is build and enabled so I can just start calling the functions to make it work? I assume this is Red Hat 8.0+, or was it also enabled in RH 7.3 and perhaps earlier versions? Thanks! --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Mouse Daemon for Linux/FreeBSD?
On Fre, 2003-02-28 at 20:54, Kendall Bennett wrote: Charl P. Botha [EMAIL PROTECTED] wrote: On Fri, Feb 28, 2003 at 10:54:17AM -0800, Kendall Bennett wrote: So I am wondering what sort of interest there would be in a high quality mouse daemon for Linux that could handle all of the mouse communications for Linux programs. The idea would be that there would be a single mouse daemon in the system that runs in user space that auto-detects the installed mouse and provides event translation for all apps in the system, including XFree86. Before you start churning out reams of code, please have a look at the new Linux kernel 2.5 input layer. Drivers are at kernel level and are presented to userland via a generic event interface. Interesting. So that means the 2.5 input layer drivers will in effect be providing a new generic interface to all Linux apps? Very nice! Do you have a good place where I can find documentation on this, or should I just grab the latest 2.5 kernel source code and look at the source itself? Is this going to be used by XFree86 any time soon? The catch of course is that we need some backwards compatibility. Perhaps a good solution would be one designed to utilise the 2.5 kernel input layer interfaces if they are present, but to use old XFree86 style code if they are not (ie: implement a user land daemon that will abstract the new 2.5 kernel interface code and make it backwards comaptible with earlier kernels). The new input layer provides backward compatible interfaces. -- 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: Mouse Daemon for Linux/FreeBSD?
On Fri, Feb 28, 2003 at 01:23:21PM -0800, Kendall Bennett wrote: Jeff Garzik [EMAIL PROTECTED] wrote: Ok, that is what I was afraid of. We need something that will work 'out of the box', so it sounds like that won't happen until 2.6 is released (or code is backported and enabled in 2.4 kernels). Like I said, it depends on your kernel configuration. Red Hat ships with the new input layer built. By built you mean it is build and enabled so I can just start calling the functions to make it work? I assume this is Red Hat 8.0+, or was it also enabled in RH 7.3 and perhaps earlier versions? The modules seem to be loaded by default on all RHL8.0 boxes I install. Beyond that, I dunno. I'm a newbie at Red Hat, really... Jeff ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Another RENDER question
Keith Packard wrote: Around 0 o'clock on Feb 28, Thomas Winischhofer wrote: The hardware I am dealing with does not support ARGB textures (at least not in 2D level, and I don't want to mess with DRI), but alpha blended bit blits. Using the '3D' hardware needn't entail dealing with DRI. The MGA driver does precisely that for Render acceleration. Alright. That should be possible. Can anyone explain to me what exactly (in the words of common 3D language) the mga driver does? The register setup is totally uncommented in the driver code. I went through my docs for the 3D registers for the hardware I am dealing with (SiS 300 series) and I saw no sort of command for just applying a texture mapping or anything similar. I can only define vertices for drawing primitives like triangle, line and point - which is rather complicated, partly because all coordinates are in floating point format. Furtherly, I can define textures (and Z buffers and alpha settings and a lot of other stuff). But it seems the texture mapping is done based on the results of the setup engine (which does the drawing primitives) in the transformation phase. I saw no command for doing a simple transformation without firing the setup engine (ie issueing a drawing primitive) before. Sorry if that sounds rookie-like - fact is I am a rookie on the area of 3D programming. Is there any 3D expert around who could give me a hint? Docs can be provided on request. The difference being: While ARGB textures contain an alpha value for each pixel, the alpha blended bit blits render with a static alpha value for all of the bitmap data. It might be of some use; applications can specify this operation through Render with a single-pixel tiled 'mask' operand to composite, but it won't speed up text or geometric operations at all. As Mark pointed out I will save the code I already wrote for features like translucent windows. Thomas -- Thomas Winischhofer Vienna/Austria mailto:[EMAIL PROTECTED] *** http://www.winischhofer.net ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple video consoles
On Fre, 2003-02-28 at 21:04, Sven Luther wrote: On Fri, Feb 28, 2003 at 02:06:35PM -0500, David Dawes wrote: On Fri, Feb 28, 2003 at 06:27:20PM +0100, Sven Luther wrote: BTW, is it normal that SDL games requesting 640x480 try to set it even if i did only specify 1024x768 in the monitor modes, and thus give blank screens ? I observed this both in my being worked on driver and in the vesa driver (using frozen-bubbles and solarwolf in fullscreen mode). I've seen games that just put a 640x480 window in one corner of the 1024x768 screen when there's no 640x480 monitor mode available. Well, apparently SDL will default to the next higher supported mode, but apparently something is broken there. But still, X should not try setting a mode not declared in the XF86Config file, whatever the app asks. Have you checked the log file? Maybe modes are added from DDC, by RandR, ... ? -- 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: basic blt programming on ATI Radeon
On Don, 2003-02-27 at 07:30, [EMAIL PROTECTED] wrote: I am writing a blt funtion to transfer a rectangular area image data from offscreen to onscreen on ATI Radeon 7500 graphic card. But after lots of tries, I still couldn't see the image on my screen.:( Can someone help me check this out ? From the blt example code ( for windows) provided by ATI doc, the major steps include Radeon initialization, reading image data to (src_x, src_y) in frame buffer, setting bunch of related registers, and then initiating the blt operation by setting the initiator register. The resolution is set to 800x600x8. The following is my code. [...] Questions: 1. Is Radeon_WaitForFifo necessary if there are enough entries in command fifo? How do you know there are enough entries without using it? :) 2. If command fifo full, does that mean I cannot set registers successfully until needed entries are available? That would be a rather harmless scenario I guess. Bad things can happen when the FIFO overflows. 3. Do I have to set some registers at Radeon initialization step? Possibly. Have you looked at the XFree86 radeon driver to verify you're initializing all the registers it initializes for 2D acceleration? -- 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: NVidia driver (open source) on Apple Powerbook G4 12
On Thursday 27 February 2003 03:14, Mark Vojkovich wrote: I'm running X 4.3 for Debian from http://penguinppc.org/~daniels/. It works so far, but the framebuffer (openfirmware framebuffer) doesn't get restored correctly if I quit X or change with ctrl-alt-F1 back to console. The screen stays black but I can do everything as normal (type reboot blindly or switch back to X, ...). There were big endian fixes to the nv driver as recent as Wed Feb 5 01:21:11 2003 UTC. I think that missed RC1 by a day. If you can't get it to work on something newer (like RC2) let me know. I just compiled the CVS version from yesterday. I did not install the whole XFree86 from the CVS (hard to handle depencies and so on...) but replaced the existing nv_drv.o from penguinppc.org/~daniels's X 4.3 with the one compiled from recent X CVS source. Unfortunately the problem mentioned above persists. Any other hints? best regards, Christoph ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: NVidia driver (open source) on Apple Powerbook G4 12
On Sat, 1 Mar 2003, Christoph Pittracher wrote: On Thursday 27 February 2003 03:14, Mark Vojkovich wrote: I'm running X 4.3 for Debian from http://penguinppc.org/~daniels/. It works so far, but the framebuffer (openfirmware framebuffer) doesn't get restored correctly if I quit X or change with ctrl-alt-F1 back to console. The screen stays black but I can do everything as normal (type reboot blindly or switch back to X, ...). There were big endian fixes to the nv driver as recent as Wed Feb 5 01:21:11 2003 UTC. I think that missed RC1 by a day. If you can't get it to work on something newer (like RC2) let me know. I just compiled the CVS version from yesterday. I did not install the whole XFree86 from the CVS (hard to handle depencies and so on...) but replaced the existing nv_drv.o from penguinppc.org/~daniels's X 4.3 with the one compiled from recent X CVS source. Unfortunately the problem mentioned above persists. Any other hints? Hmmm. I've never tried it on a PowerBook. I guess I will have to see if I can borrow one from around here to play with. Unfortunately, that means it's unlikely to be fixed in 4.3 (I recall having a difficult time with Linux PPC installation). Can you VT switch back to the X-server OK, and startx again after quitting? If so, it's probably just a matter of not enough stuff being saved and restored in the UnLoad/LoadStateExt functions in riva_hw.c. Probably some of the CRTC registers, possibly something specific to the PowerBook. I supposed it could also be an offb issue. If you wanted to collect some data you could try reading chip-PMC[0x0004/4] at the top of nv10GetConfig() just to see what state that was in before the X-server touched it. Have you tried it in different depths? Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[PATCH] Re: xmag segv's
Yeah, that's what it's trying to do. The problem is it doesn't check
the first child of root for InputOnly, only 2nd children on up. E17 has
an InputOnly window as the first child of root, which breaks xmag. I'd
suggest the following patch. It checks to make sure all children are
InputOutput and will only return one that is, or the root. (I suspect
that was the original intent.)
I've also included fixes for the null pointer dereferences exhibited
when the above code failed. What do you think?
Summary of change:
Fix case in xmag which would cause a BadMatch during a X_GetImage for
single child of root class InputOnly. Also do some null pointer
protection.
--
Kevin
Mark Vojkovich wrote:
On Wed, 26 Feb 2003, Kevin Brosius wrote:
The background reports Depth: 0 with xwininfo. That looks like a
problem.
The x,y,... to the GetImage seem good, 1103,302,64,64.
What does xwininfo say the Class is? It should be InputOnly.
Depth 0 windows are InputOnly.
Can you poke around in xmag's FindWindow? Maybe the logic
in there is busted. I'm not really following what it's supposed
to be doing. Looks like it starts at the root and works it's way
towards the pointer (out of the screen) until the last InputOutput
window, which is the only type it can grab from. I would guess it
wants the frontmost InputOutput window under the pointer.
Mark.
--
Kevin
Mark Vojkovich wrote:
Are there depth 32 windows or something? If not
GetImageAndAttributes should call XGetImage on the
root window. It looks like the checks in there are OK.
Can you check the x,y,width,height to that first XGetImage
in GetImageAndAttributes?
Mark.
On Tue, 25 Feb 2003, Kevin Brosius wrote:
Of course, that's not what causes the X_GetImage failure... That
happens here:
in DragEH()
case ButtonRelease: /* end drag mode */
if (event-xbutton.button == Button1) { /* get image */
/* Problem: You can't get bits with XGetImage outside of its
window.
* xmag will only do a GetImage on the actual window in
the case
* where the depth of the window does not match the depth
of
* the root window.
*/
GetImageAndAttributes(FindWindow(event-xmotion.x_root,
event-xmotion.y_root),
event-xbutton.x_root,
event-xbutton.y_root,
srcWidth, srcHeight, data);
the GetImage call above generates the BadMatch. The embedded
FindWindow() calls seem to succeed.
Kevin Brosius wrote:
Latest CVS xmag (yesterday, changelog at 948.) No, there's no overlay,
this is on an ATI Mach64 at depth 16. I do think e17 uses a virtual
root window however. Here's the problem:
(gdb) r
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 73 (X_GetImage)
Serial number of failed request: 2375
Current serial number in output stream: 2375
Program received signal SIGSEGV, Segmentation fault.
0x0804b48d in GetMinIntensity (data=0x805b5b8) at xmag.c:908
(gdb) bt
#0 0x0804b48d in GetMinIntensity (data=0x805b5b8) at xmag.c:908
#1 0x0804b7cf in PopupNewScale (data=0x805b5b8) at xmag.c:975
#2 0x0804a909 in DragEH (w=0x805fc38, closure=0x805b5b8,
event=0xb460, continue_to_dispatch=0xb38f
\001`ôÿ¿8ü\005\bdf\005\b8·\005\b\a) at xmag.c:664
#3 0x400accf4 in XtDispatchEventToWidget () from
/usr/X11R6/lib/libXt.so.6
#4 0x400ad767 in _XtDefaultDispatcher () from /usr/X11R6/lib/libXt.so.6
#5 0x400ad944 in XtDispatchEvent () from /usr/X11R6/lib/libXt.so.6
#6 0x400adea2 in XtAppMainLoop () from /usr/X11R6/lib/libXt.so.6
#7 0x0804bd43 in main (argc=1, argv=0xb554) at xmag.c:1105
#8 0x402204a2 in __libc_start_main () from /lib/libc.so.6
(gdb) l
static Pixel
GetMinIntensity(hlPtr data)
{
XColor *colors = NULL, *mptr, *tptr;
int i, ncolors;
if (data-win_info.colormap == DefaultColormap(dpy, scr))
return BlackPixel(dpy, scr);
ncolors = Get_XColors(data-win_info, colors);
mptr = tptr = colors; tptr++;
903 for (i=1; incolors; i++) {
904 if ((int)Intensity(mptr) (int)Intensity(tptr))
905 mptr = tptr;
906 tptr++;
907 }
908 return mptr-pixel;
909 }
910
(gdb) p ncolors
$1 = 0
I pasted some extra lines from the function in question. Get_XColors
returns 0 in my case, and since mptr was set to NULL already, the return
segv's when hit (the for loop falls through.) What should happen in
this case? Can we just return BlackPixel like the previous
