Re: XInput: The device type in XListInputDevices comes up again...
Bryan W. Headley writes: Egbert Eich wrote: A lot of error conditions can only be fixed by the administrator. Can you come up with a really good real life example? I suppose 'Battery Low' would be one. That's the easiest one for everyone to grasp. Let's see: problems with the input device (it didn't accept programming/switch mode commands we asked for). I'm trying to think what would be a less-than-disasterous but still inconvenient situation for a video card to report... OK. That makes sense. However if your protocol supports mode setting you can implement this as the success status reported back. When you were talking about QoS messages I was thinking more of an event-type-of-thing. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Bryan W. Headley writes: True, and that's a whole other set of problems. At least, in your example, everything is in the XI layer, if not in the individual driver. I'm more worried about an XI layer that talks to its drivers, but there's also a layer in Misc that does the same thing, but perhaps supercedes the XI layer, but all of that has been replaced by something in a third layer. No, not necessarily. If you take a look at the current xf86misc extensions they implement setting of some mouse parameters. Most of them are clearly related to mouse HW and are well separable form the XI view of things. How this will turn out in the end is probably not so much a matter of implementation but of discipline and coordination. Yes! But also documentation, both in terms of self-documenting code and the manuals in the ./doc directory. (Because, whoever looks at docs? :-) Right. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: DRI and Silicon Motion
Just so. Unless otherwise specified, cat_fish's code would be considered a work for hire, and copyright would belong to the employer. :-) Thank you all for your concern in this matter, but it is clearly covered in my proposal that the work will remain open source and be re-submitted to XFree (and to the DRI project as well, since it appears that is a separate code tree). My primary concern at this time is providing an accurate estimate up front for how much work this will be. Thank you all for your advice and help. If this thing gets approved, I will most certianly be back with more questions. Noel. -- A precariously balanced mixture of myopic optimism and rampant paranoia. _ Need more e-mail storage? Get 10MB with Hotmail Extra Storage. http://join.msn.com/?PAGE=features/es ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Egbert Eich wrote: OT for a second... I've read somewhere that the Xv layer has problems with the VIA CLE266 driver, and that you were working on it. 1) True? (Did you know you were working on it, or is this someone's mistaken impression?) 2) How is it going? 3) I notice that Via also has L4V and DRM code for X, too. Do you know if they're putting it into the distribution? 4) That hardware MPEG-2 decoder of theirs is going to drive everyone nuts. I'm already there... -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Egbert Eich wrote: Bryan W. Headley writes: True, and that's a whole other set of problems. At least, in your example, everything is in the XI layer, if not in the individual driver. I'm more worried about an XI layer that talks to its drivers, but there's also a layer in Misc that does the same thing, but perhaps supercedes the XI layer, but all of that has been replaced by something in a third layer. No, not necessarily. If you take a look at the current xf86misc extensions they implement setting of some mouse parameters. Most of them are clearly related to mouse HW and are well separable form the XI view of things. That just illustrates the problem. Who would think to look at the Misc extension for that? -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
i855 and 1400x1050
Hi everybody I'm a linux Xfree86 user, and my laptop has an LCD screen with 1400x1050 native resolution. the internal video chipset is an intel 855GM. After some hours of trying i figured out there's no way of getting that resolution under XFree86, due to the fact that the current i810 driver reads the available resolutions from the bios and completely ignores the modelines in the XF86Config file. I'm inquiring if there is any plan to overcome this limitation. I'm a cs student and have some knowledge in system programming, so i'm available to help the developent of this 'patch', should this be needed, and i'm also available to test/debug beta versions. I'd be grate to be contacted by people that are actually taking care of the i810 driver developement. Best Regards Alessandro Temil ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Egbert Eich wrote: Bryan W. Headley writes: Egbert Eich wrote: A lot of error conditions can only be fixed by the administrator. Can you come up with a really good real life example? I suppose 'Battery Low' would be one. That's the easiest one for everyone to grasp. Let's see: problems with the input device (it didn't accept programming/switch mode commands we asked for). I'm trying to think what would be a less-than-disasterous but still inconvenient situation for a video card to report... OK. That makes sense. However if your protocol supports mode setting you can implement this as the success status reported back. Failures can occur at any time, not just at the time when a status message is being created. That is why, for QoS messages, the driver is the initiator of the message. (I also agree that status reply messages are good. And would go so far as to suggest that they could be complex, or long messages. E.g., you ask it for its status, and it replies with a message with several Atoms interspersed. Only to differentiate it from an API that only allows the return of an int, or something...) Depending on the contract of the driver, QoS messages can be sent very irregularly (once every unexplained failure, aka, once every battery failure) or perhaps once every heartbeat. That depends on what the driver writer thinks is desirable. -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: i855 and 1400x1050
Hi, Alessandro Temil schrieb: I'm a linux Xfree86 user, and my laptop has an LCD screen with 1400x1050 native resolution. the internal video chipset is an intel 855GM. After some hours of trying i figured out there's no way of getting that resolution under XFree86, due to the fact that the current i810 driver reads the available resolutions from the bios and completely ignores the modelines in the XF86Config file. The problem is: The current i810 driver does not only read the available resolutions from the BIOS but also uses the BIOS to set the video mode. So if the BIOS doesn't know of 1400x1050, it won't set it. I think there are two solutions: - Change the BIOS to know of 1400x1050. This should be easy for manufacturer of the notebook but considerably harder than my 855patch (for the video memory issue) for anyone else. - Rewrite the i810 driver so it bypasses the BIOS like the Windows driver does. I'm not aware whether Intel would provide the required documentation to the the open source community. Christian ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
XF86Config handler
Hi,
I'm new to this mailing list and I don't know if this was already
discussed. I updated from 4.3.99.9 to 4.3.99.11 and got the following
problem:
(==) Using config file: /etc/X11/XF86Config
(EE) Cannot locate a core pointer device.
(EE) Unable to determine the screen layout
(EE) Error from xf86HandleConfigFile()
I don't know wich changes were made for this to happen. My guess goes to
the following:
397. When a core keyboard or core pointer cannot be found in the
configuration, create default ones. The pointer part of this
requires some changes to the mouse driver (coming later) before
the default core pointer configuration will be useful on most
platforms (David Dawes).
I checked out 'xc/programs/Xserver/hw/xfree86/common/xf86Config.c' and
found two things:
if (!havePointer) {
...some code...
/*
* If no core pointer config section found, create a
* default one.
*/
...some more code...
}
The above code seems to me to be the changes mentioned in 397.
if (foundPointer) {
...some code...
} else {
/* This should never happen. */
xf86Msg(X_ERROR, Cannot locate a core pointer device.\n);
return FALSE;
}
Note the This should never happen. I have no clue how the internal
config-file parsing works, but could it be that the 397's change broke
something in the core pointer detection code?
Björn Martins Paz
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: i855 and 1400x1050
Christian Zietz wrote: Hi, Alessandro Temil schrieb: I'm a linux Xfree86 user, and my laptop has an LCD screen with 1400x1050 native resolution. the internal video chipset is an intel 855GM. After some hours of trying i figured out there's no way of getting that resolution under XFree86, due to the fact that the current i810 driver reads the available resolutions from the bios and completely ignores the modelines in the XF86Config file. The problem is: The current i810 driver does not only read the available resolutions from the BIOS but also uses the BIOS to set the video mode. So if the BIOS doesn't know of 1400x1050, it won't set it. I think there are two solutions: - Change the BIOS to know of 1400x1050. This should be easy for manufacturer of the notebook but considerably harder than my 855patch (for the video memory issue) for anyone else. I know this but at the moment i'm getting weak support from the manufacturer (acer), as they say they give no support to linux (my try to explain the difference that passes from a linux driver bug and a bios bug had little effect, as you can imagine) - Rewrite the i810 driver so it bypasses the BIOS like the Windows driver does. I'm not aware whether Intel would provide the required documentation to the the open source community. This was the thing i'm inquiring on. Intel seemed to be more collaborative, they promptly replied that the problem was submitted to the software engineers, but after that i had no more news. I'll write them asking for the documentation, i don't think there is any broken industrial secret with publishing the correct register addresses that drive the video mode change, i hope to get some response soon. Best Regards Alessandro ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XF86Config handler
On Fri, Sep 05, 2003 at 03:03:18PM -0300, [EMAIL PROTECTED] wrote:
Hi,
I'm new to this mailing list and I don't know if this was already
discussed. I updated from 4.3.99.9 to 4.3.99.11 and got the following
problem:
(==) Using config file: /etc/X11/XF86Config
(EE) Cannot locate a core pointer device.
(EE) Unable to determine the screen layout
(EE) Error from xf86HandleConfigFile()
I don't know wich changes were made for this to happen. My guess goes to
the following:
397. When a core keyboard or core pointer cannot be found in the
configuration, create default ones. The pointer part of this
requires some changes to the mouse driver (coming later) before
the default core pointer configuration will be useful on most
platforms (David Dawes).
I checked out 'xc/programs/Xserver/hw/xfree86/common/xf86Config.c' and
found two things:
if (!havePointer) {
...some code...
/*
* If no core pointer config section found, create a
* default one.
*/
...some more code...
}
The above code seems to me to be the changes mentioned in 397.
if (foundPointer) {
...some code...
} else {
/* This should never happen. */
xf86Msg(X_ERROR, Cannot locate a core pointer device.\n);
return FALSE;
}
Note the This should never happen. I have no clue how the internal
config-file parsing works, but could it be that the 397's change broke
something in the core pointer detection code?
This is fixed in the current CVS. Also, I sent a patch for 4.3.99.11
here last week. I've attached it again here.
David
--
David Dawes
Founder/committer/developer The XFree86 Project
www.XFree86.org/~dawes
Index: xf86Config.c
===
RCS file: /home/x-cvs/xc/programs/Xserver/hw/xfree86/common/xf86Config.c,v
retrieving revision 3.272
diff -u -r3.272 xf86Config.c
--- xf86Config.c24 Aug 2003 20:52:30 - 3.272
+++ xf86Config.c27 Aug 2003 02:26:17 -
@@ -1451,7 +1451,7 @@
indp[count - 1].extraOptions = xf86addNewOption(NULL, CorePointer, NULL);
indp[count].identifier = NULL;
servlayoutp-inputs = indp;
-} else {
+} else if (!havePointer) {
/* This should never happen. */
xf86Msg(X_ERROR, Cannot locate a core pointer device.\n);
return FALSE;
@@ -1473,7 +1473,7 @@
indp[count - 1].extraOptions = xf86addNewOption(NULL, CoreKeyboard, NULL);
indp[count].identifier = NULL;
servlayoutp-inputs = indp;
-} else {
+} else if (!haveKeyboard) {
/* This should never happen. */
xf86Msg(X_ERROR, Cannot locate a core keyboard device\n);
return FALSE;
Re: i855 and 1400x1050
On Fri, 05 Sep 2003 20:04:19 +0200, Alessandro Temil wrote: Christian Zietz wrote: The problem is: The current i810 driver does not only read the available resolutions from the BIOS but also uses the BIOS to set the video mode. So if the BIOS doesn't know of 1400x1050, it won't set it. I think there are two solutions: - Change the BIOS to know of 1400x1050. This should be easy for manufacturer of the notebook but considerably harder than my 855patch (for the video memory issue) for anyone else. I know this but at the moment i'm getting weak support from the manufacturer (acer), as they say they give no support to linux (my try to explain the difference that passes from a linux driver bug and a bios bug had little effect, as you can imagine) This path is hopeless; the engineers at Acer have absolutely no idea how to program the graphics chipset. Hoewever, I am absolutely astonished that the graphics BIOS on a 1400x1050 panel does not know how to set a 1400x1050 mode. That means, for example, that the kernel console driver could never set a mode that fills the panel. Does the i810 driver list the modes it got from the BIOS in the server log? I have a utility to read the BIOS mode list and display the results; I'll see if I can dig it up for you. - Rewrite the i810 driver so it bypasses the BIOS like the Windows driver does. I'm not aware whether Intel would provide the required documentation to the the open source community. This was the thing i'm inquiring on. Intel seemed to be more collaborative, they promptly replied that the problem was submitted to the software engineers, but after that i had no more news. I'll write them asking for the documentation, i don't think there is any broken industrial secret with publishing the correct register addresses that drive the video mode change, i hope to get some response soon. It will be interesting to see if you get a response. Many manufacturers DO, in fact, protect their register specifications as confidential intellectual property. -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: i855 and 1400x1050
On Fri, Sep 05, 2003 at 11:25:35AM -0700, Tim Roberts wrote: On Fri, 05 Sep 2003 20:04:19 +0200, Alessandro Temil wrote: Christian Zietz wrote: The problem is: The current i810 driver does not only read the available resolutions from the BIOS but also uses the BIOS to set the video mode. So if the BIOS doesn't know of 1400x1050, it won't set it. I think there are two solutions: - Change the BIOS to know of 1400x1050. This should be easy for manufacturer of the notebook but considerably harder than my 855patch (for the video memory issue) for anyone else. I know this but at the moment i'm getting weak support from the manufacturer (acer), as they say they give no support to linux (my try to explain the difference that passes from a linux driver bug and a bios bug had little effect, as you can imagine) This path is hopeless; the engineers at Acer have absolutely no idea how to program the graphics chipset. Hoewever, I am absolutely astonished that the graphics BIOS on a 1400x1050 panel does not know how to set a 1400x1050 mode. That means, for example, that the kernel console driver could never set a mode that fills the panel. Does the i810 driver list the modes it got from the BIOS in the server log? I have a utility to read the BIOS mode list and display the results; I'll see if I can dig it up for you. It does list the modes, and it is common for modes matching panels like this to not be listed. It might be worth comparing it to the list you get when using the 'vesa' driver. Can someone with one of these laptops try that and post the results? David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
synaptics driver.
(in reponse to the thread 'synaptics lockups', formerly 'radeon lockups') I am the original author of 'tpconfig', from which the synaptics driver was derived. Bruce Kall later took over tpconfig development from me. Warren Turkal got in touch with us on 2 sept and asked about relicensing. Bruce and I (at least) are unopposed. My original tpconfig implementation was from scratch, so there are no prior copyright holders to be concerned with (to reply to Mike Harris' email of 2 sep 2003 on this list). A complete code history of the synaptics driver (as far as I could determine, at least) is at http://cscott.net/Projects/Synaptics/ I am hopeful that we can get all of the remaining authors to agree to a relicensing. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=168794 for my proposed dual-license text. --scott South Africa SSBN 743 CIA DES Cheney mail drop jihad Mk 48 colonel SEAL Team 6 AK-47 President Ft. Meade Blair DNC operation Philadelphia ( http://cscott.net/ ) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Shared library inter-dependencies
Hi, I asked this once before but unfortunately I lost the reply when I moved to Mozilla for my mail reader, so I'd like to ask the question again, or open up the debate. I would very VERY much like to see the XFree86 build correctly set up its dependencies for shared libraries. For example, make sure that Xext always has X11.so.6 as a dependency. This makes life a lot easier for folks, and obviates the need for linking with the same library many times (not all systems are thus flawed, but many are). Ideally, each library should be build with -z text, so that it has no unresolved relocations. I believe that Darwin actually requires this (if I remember the previous reply to this question correctly), so there is at least some precedent in the build for handling this. If this is true, and these inter-dependencies are already addressed for Darwin, then it will most probably be a simple matter of adjusting the required *Lib.rules files to link against the dependent libraries. Comments? Suggestions? Kean ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
setjmp wrappers
Remember last Feburary and March there was a big discussion about xf86setjmp? Part of that discussion involved a SIGSEGV or SIGBUS in the freetype2 code when a font was not found. Well, I'm seeing the same thing (on ia64). At the time it was pointed out that one can never wrap setjmp because setjmp has bad behavior if its called from within a function that returns, which is exactly what a wrapper is. The setjmp code was reworked a couple of months ago (in part to account for libc differences). The current implementation has these code fragments: ftstdlib.h: --- #define DONT_DEFINE_WRAPPERS #define DEFINE_SETJMP_WRAPPERS #include xf86_ansic.h #undef DONT_DEFINE_WRAPPERS xf86_libc.h: #if defined(XFree86LOADER) \ (!defined(DONT_DEFINE_WRAPPERS) || defined(DEFINE_SETJMP_WRAPPERS)) #undef setjmp #define setjmp(a) xf86setjmp_macro(a) #undef longjmp #define longjmp(a,b)xf86longjmp(a,b) #undef jmp_buf #define jmp_buf xf86jmp_buf #endif As far as I can tell when one builds the freetype module for the loadable server you're not going to get any wrappers except for setjmp and this is bad because you can't wrap setjmp. As a trial I built both a static and a loadable server. The static server ran fine, but the loadable server dies with a SIGBUS in the freetype code when a setjmp/longjmp is executed. Pretty much what I expected. I'm wondering if I'm missing something, but its a fact you can't wrap setjmp right? And why would you turn off all wrappers except setjmp? Is this really right? I reread the original discussion and part of had to do with how to implement setjmp in modules that are supposed to be system neutral (i.e. must use wrappers) when one has this exception of a clib function that can't be wrapped. What ever came of that? -- John Dennis [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
