Re: Multiple Monitors
On Tue, Mar 02, 2004 at 12:59:52PM -0500, David Dawes wrote: Section Screen Identifier Screen0 Device Videocard0 DefaultDepth 24 SubSection Monitor0 SubSection Display Depth 16 Modes1024x768 800x600 640x480 EndSubSection SubSection Display Depth 24 Modes1024x768 800x600 640x480 EndSubSection EndSubSection SubSection Monitor1 SubSection Display Depth 16 Modes1024x768 800x600 640x480 EndSubSection SubSection Display Depth 24 Modes1024x768 800x600 640x480 EndSubSection EndSubSection EndSection I prefer #1. You might want to look into NVIDIA's TwinView options. That is, stuff like orientation and panning domains. And please don't break binary compatibility with drivers who parse the current Monitor info in the ScrnInfoRec. When I was looking at this, I was adding the new fields at the end, and filling in the current fields with the first monitor's data for compatibility with drivers that don't look beyond that. BTW, while we are at it, please let's add support for depth independent modelines. Something like : SubSection Display Depth 16 24 Modes1024x768 800x600 640x480 EndSubSection Or even : SubSection Display Modes1024x768 800x600 640x480 EndSubSection Which would use the modes for all depth. I doubt newer cards have per depth modes limitations anymore. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: help new driver
On Wed, Feb 25, 2004 at 07:30:49PM -0500, Mike A. Harris wrote: On Thu, 26 Feb 2004, dave wrote: Date: Thu, 26 Feb 2004 12:24:02 +1300 From: dave [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 Subject: help new driver I am writing a driver and need to now what copyright GPL stuff I need to put in my source files What driver are you speaking about ? The existing drivers are under an MIT/X11 style license, which allows their source code to be shared with pretty much anything, including GPL licensed code. Making your driver MIT/X11 licensed, or dual licensing it as MIT/X11 and GPL, would allows other drivers to be able to benefit from sharing code with your driver as well. Of course it is totally up to you what license you would prefer to use. Yeah, i would recomend a MIT/X11 GPL dual licence, that would be nice, so the code could later be shared by the linux kernel, among others. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 3D support for radeon 9600 pro (ppc)
On Thu, Feb 19, 2004 at 03:06:13PM -0800, Ian Romanick wrote: jaspal kallar wrote: I know there is already 2D support for the radeon 9600 pro in the upcoming 4.4 release. My question is if I buy an Apple Powermac G5 with a radeon 9600 pro card will I eventually in the future be able to get 3D support on the powerpc platform (not x86!!) ? Only if ATI ports their closed-source driver to PowerPC. And since they probably wont do it, there is little hope there. Maybe you should send Apple some mail, telling them that you are thinking about asking a linux machine, and that the G5 Powermac looks interesting, but that the lack of 3D linux support would be an argument to go for an x86 box instead. I think that ATI is missing something here. I believe that Powerpc hardware with ATI graphics represent a ever growing linux installed base, with the G5 Powermac, with the new powerbooks, as well as with non-apple powerpc boxes like the pegasos motherboards. But then, it is probably that the ATI drivers are not endian clean, and that they can't be bothered to make a powerpc build, even an unsupported one, probably because of that, or maybe for some hidden reason like the intel-ATI connection or something such. Anyway, i believe that the fastest 3D solution on powerpc hardware right now would be a 3Dlabs wildcat VP graphic card, which have lowered in price quite some lately, together with the paying AcceleratedX server, altough they don't officially distribute powerpc binaries too, at least they ship sparc ones, so they should be endian clean. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 3D support for radeon 9600 pro (ppc)
On Fri, Feb 20, 2004 at 07:55:27AM -0800, Ian Romanick wrote: Sven Luther wrote: I think that ATI is missing something here. I believe that Powerpc hardware with ATI graphics represent a ever growing linux installed base, with the G5 Powermac, with the new powerbooks, as well as with non-apple powerpc boxes like the pegasos motherboards. But then, it is probably that the ATI drivers are not endian clean, and that they can't be bothered to make a powerpc build, even an unsupported one, probably because of that, or maybe for some hidden reason like the intel-ATI connection or something such. Even if it is ever growing, it probably still only represents 1% of 1% of their total market. It would take some pretty extreme dedication to the Linux movment to make a business case to devote even an single engineer to that cause. :( Whatever. The truth is that outside of x86, there is actually not a single graphic card vendor with recent graphic card which provide 3D driver support. Until something changes, this mean the death of 3D support on non x86 linux. And then, seriously, do you believe it it will need a full time engineer to make a powerpc build ? If the drivers were endian clean, then it would only be a matter of launching a build, and track the occasional arch related problem. Hell, if a volunteer project can make it, why can't ATI ? And i would do it, if ATI would give me access to the needed sources, under strong NDA or whatever, i would build their drivers, but they don't want to. Chances of Nvidia releasing powerpc binaries are worse even, altough it is possible that their drivers are more endianess clean, if they share the code with the OS X driver, which i know ATI does not. The only real hope is that ATI will release the R300 specs once the R400 is released, but even there, i only half believe it. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 4.4.0 RC3
On Wed, Feb 18, 2004 at 02:39:01AM -0500, Mike A. Harris wrote: On Tue, 17 Feb 2004, David Dawes wrote: Also check the LICENSE document http://www.xfree86.org/~dawes/pre-4.4/LICENSE.html. There is a lot of FUD being circulated about the licensing, so check here for the facts. Also check out the FSF's Free Software definition and their list of licenses, as well as the OSI's Open Source Definition. There are links to these sites from our LICENSE document. In particular, follow up with the BSD licences (original and revised), the FreeType License (FTL), the SGI Free Software License (which applies to GLX and CID), and the Apache 1.1 licence. Don't rely on the FUD being circulated by people who can barely hide their prejudice. Go straight to the definitive sources on licensing issues, namely the FSF and the OSI, and come to your own conclusions. So I must totally agree with you David. People should indeed go to the definitive sources on open source licensing issues, the FSF and the OSI. Interestingly enough, neither the XFree86 license version 1.0, nor the new 1.1 license are listed as OSI approved open source licenses: http://www.opensource.org/licenses/index.php Going to the Free Software Foundations site to see their list of approved free software licenses, the XFree86 license version 1.0 and 1.1 are also noteably missing: http://www.fsf.org/licenses/license-list.html The FSF does have the following: The X11 license. This is a simple, permissive non-copyleft free software license, compatible with the GNU GPL. XFree86 uses the same license. This is sometimes called the MIT license, but that term is misleading since MIT has used many licenses for software. However that statement is inaccurate, as the parts of the XFree86 source code which are copyright by XFree86.org, are under either the XFree86 license version 1.0, or XFree86 license version 1.1. The simple conclusion, is that XFree86 is not free software, as defined by the Free Software Foundation nor open source software as defined by the Open Source Initiative, however there are a few inaccuracies present on both of these websites which need to be fixed, in order to not mislead people into beleiving XFree86 is MIT/X11 licensed. I cannot agree with that. The new XFree86 licence is indeed free software, at least as far as Debian is concerned, or so Branden told me. The real problem here is not about the freeness of the licence, but about the GPL incompatibility of it, which is problematic for the client side libraries. There seems to be a tentative agreement to not change the licence on these client side libraries, but only on the server code, which should make any arguments here mostly moot. David, any advancement on this ? Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Manufacturers who fully disclosed specifications for agp cards?
On Mon, Feb 02, 2004 at 11:42:28AM -0600, Ryan Underwood wrote: There are some 3dlabs and mga databooks floating around on the net but I don't know if they are legal to obtain/link to. Well, there is documentation for 3Dlabs permedia2 floating around, and i believe it is legal. They were obtained from the TI web site, who had it online while they manufactured their own permedia2 chips, before 3Dlabs asked them to not do so (even sued them or something). I don't know what action 3Dlabs can take against people who got the specs in the time span TI was legally distributing them, but i really doubt they care, since the pm2 is rather ancient. Also 3Dlabs is rather liberal in providing specs under NDA. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Manufacturers who fully disclosed specifications for agp cards?
On Tue, Feb 03, 2004 at 09:21:53AM -0600, Ryan Underwood wrote: On Tue, Feb 03, 2004 at 04:41:07AM -0500, Mike A. Harris wrote: That's not entirely true... Some people do have /some/ of the R300 specs under NDA. Is there some special circumstance you have to fall under to qualify for R300 specs? It seems there are a lot of people wishing they had them and not a lot of people saying I've got em... :) And in any way, i guess this doesn't include the 3D/DRI parts. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Linux-fbdev-devel] Re: [forum] Re: Announcement: Modification to the base XFree86(TM) license.
On Sat, Jan 31, 2004 at 01:06:23PM +, Andrew C Aitchison wrote:
On Sat, 31 Jan 2004, Sven Luther wrote:
On Sat, Jan 31, 2004 at 09:10:22AM +, Andrew C Aitchison wrote:
For several years the mga fb kernel driver has supported dual head and/or
dvi on cards which aren't supported by the XFree86 driver (unless you
use the mga_hal). I've wanted to use kernel code to add this support to
XFree86, but been put off by the licence problem.
And, have you asked the mgafb driver author about this ?
You can hardly complain about lack of back traffic if you didn't ask him
about it, and if you did, it would be interesting to this discussion to
know what the problems where.
The Author ?
This is open source code; there may be 27 authors of the relevant file.
In XFree86 code I wouldn't know how to find the author of a file without
looking at that file. My {limited ,mis}understanding of clean room coding
makes me wary of reading any source unless I know that its licence will
allow me to do what I wish.
This is not acceptable. You are making wild accusations, and didn't even
try to contact the relevant people. To my knowledge, Petr is the sole
author of matroxfb, and there should not have been any problem in at
least asking him about this.
OK. So I've probably been paranoid and lazy, but if the fbdev licence
had been compatible with the XFree86 one, I would have done the work.
As it is the bar was raised high enough to stop me.
Yeah, whatever, but with you asking that the fbdev drivers change their
licence, it is the same thing as the GPL zealots not liking the new
XFree86 licence.
The way to solve this is by cooperation, not by staying aloft and
pointing the finger to the opposite side.
So, for one developer at least, the reason there has been no traffic
from fbdev to XFree86 is *directly* because of the licence issue.
Yeah, but again, was it so because of a definite will on the fbdev
authors part, or because you didn't ask him ?
Isn't the aim of open source licences is to allow people to use the code
without tracking down the author and obtaining permission ?
Yes. But the aim of GPLed code is that those author give you the
permission, but also force you to give back the changes you do under the
same licence. And altough i contribute to project with the licence the
project choose, i would never choose something else as the GPL for my
own projects. If someone else wants access to the code, they can ask me
for it, and we can discuss stuff and arrive to an arrangement.
I can do that with closed source.
Well, the only reason you need to contact the author is because you want
some additional right from him, if your project was GPLed, it was no
problem.
Friendly,
Sven Luther
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: [Linux-fbdev-devel] Re: [forum] Re: Announcement: Modification to the base XFree86(TM) license.
On Mon, Feb 02, 2004 at 08:13:45AM -0500, Harold L Hunt II wrote:
Sven Luther wrote:
On Sat, Jan 31, 2004 at 01:06:23PM +, Andrew C Aitchison wrote:
On Sat, 31 Jan 2004, Sven Luther wrote:
On Sat, Jan 31, 2004 at 09:10:22AM +, Andrew C Aitchison wrote:
For several years the mga fb kernel driver has supported dual head
and/or
dvi on cards which aren't supported by the XFree86 driver (unless you
use the mga_hal). I've wanted to use kernel code to add this support to
XFree86, but been put off by the licence problem.
And, have you asked the mgafb driver author about this ?
You can hardly complain about lack of back traffic if you didn't ask him
about it, and if you did, it would be interesting to this discussion to
know what the problems where.
The Author ?
This is open source code; there may be 27 authors of the relevant file.
In XFree86 code I wouldn't know how to find the author of a file without
looking at that file. My {limited ,mis}understanding of clean room coding
makes me wary of reading any source unless I know that its licence will
allow me to do what I wish.
This is not acceptable. You are making wild accusations, and didn't even
try to contact the relevant people. To my knowledge, Petr is the sole
author of matroxfb, and there should not have been any problem in at
least asking him about this.
Wild accusations? How do you get wild accusations from pointing out
that there may be 27 authors of the relevant file? If anyone is
making wild accusations, it is you. Andrew simply stated the point that
Ok, sorry, shouldn't have said it so, maybe it was a bit exagerated.
Still this is degenerating in GPL bashing, which will bring us nowhere.
And if you didn't make the effort to ask at least once, where will we
go. I am sure that a post to the linux-fbdev mailing list would have
solved everything, or maybe the main maintainer of the matroxfb driver ?
this is not an issue about proving whether *one* file doesn't have
issues; rather, it is the issue of having to prove that *all* files do
not have issues, and many of these files may be just as messy in
authorship as Andrew is suggesting.
Still, there is a mailing list where all linux fbdev authors are, or at
least most of them, and bitkeeper will mostly give us full history, so i
doubt it is as bad as you say.
Also, most fbdev authors have also been XFree86 contributors in the
past, so i don't really know what the problem is here.
Friendly,
Sven Luther
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: [Linux-fbdev-devel] Re: [forum] Re: Announcement: Modification to the base XFree86(TM) license.
On Mon, Feb 02, 2004 at 01:59:54PM +, Dr Andrew C Aitchison wrote:
On Sat, Jan 31, 2004 at 09:10:22AM +, Andrew C Aitchison wrote:
On Fri, 30 Jan 2004, Sven Luther wrote:
Yeah, that would be rather problematic, but anyway, most of the things
move from the XFree86 code to fbdev code, and most often, it is not code
that is copied, but the register information and such. It is always
easier to get specs if you are working for XFree86 than if you plan to
do some kernel driver work.
On Sat, 31 Jan 2004, Benjamin Herrenschmidt wrote:
The fact that it is mostly a one way is mostly due to the fact that the
main problem here is seeking for HW informations.
For several years the mga fb kernel driver has supported dual head and/or
dvi on cards which aren't supported by the XFree86 driver (unless you
use the mga_hal). I've wanted to use kernel code to add this support to
XFree86, but been put off by the licence problem.
On Sat, 31 Jan 2004, Sven Luther wrote:
And, have you asked the mgafb driver author about this ?
You can hardly complain about lack of back traffic if you didn't ask him
about it, and if you did, it would be interesting to this discussion to
know what the problems where.
On Sat, Jan 31, 2004 at 01:06:23PM +, Andrew C Aitchison wrote:
The Author ?
This is open source code; there may be 27 authors of the relevant file.
In XFree86 code I wouldn't know how to find the author of a file without
looking at that file. My {limited ,mis}understanding of clean room coding
makes me wary of reading any source unless I know that its licence will
allow me to do what I wish.
On Mon, 2 Feb 2004, Sven Luther wrote:
This is not acceptable. You are making wild accusations, and didn't even
try to contact the relevant people. To my knowledge, Petr is the sole
author of matroxfb, and there should not have been any problem in at
least asking him about this.
I didn't intend to make *any* accusations, and don't understand what
accusations I'm supposed to have made.
I clearly have to explain my starting position more clearly;
it is probably wrong, and almost certainly the cause of most of the
confusion, however it is how I came into this arguement, and maybe seeing
how I'm thinking will let you see that I wasn't making accusations.
My understanding of copyright/patents/plagarism (I'm vague and confused
about which this covers) is that merely by reading your document,
I am allowing the possibility that I may use that information in something
which I later write.
This is the principle behind cleanroom development, see
http://en.wikipedia.org/wiki/Cleanroom,
meaning 2.
If my licence to use your document doesn't allow me to do what I wish,
it is therefore better for me not to read your document.
My understanding about fbdev was that it was GPL-licenced, and that
it is *not* OK to incorporate GPL-ed code into XFree86.
Since I can't read the source code, I can't see who owns the bit I'm
interested in and can't therefore ask permission to use it under a
different licence.
I merely wished to point out that the GPL-licence *had* affected my
decision not to copy anything from fdbdev into XFree86.
Call me lazy, mis-informed, confused and paranoid, but I resent the
suggestion that I've been making accusations, wild or tame.
Well, i seriously doubt that reading the first lines of a file would
contaminate you, after all you could use head to look at them or
something. Also, you could have written to linux-fbdev mailing list if
you were interested, or even have asked on [EMAIL PROTECTED], and those
with interest in fbdev matters would have responded to you.
OK. So I've probably been paranoid and lazy, but if the fbdev licence
had been compatible with the XFree86 one, I would have done the work.
As it is the bar was raised high enough to stop me.
Yeah, whatever, but with you asking that the fbdev drivers change their
licence, it is the same thing as the GPL zealots not liking the new
XFree86 licence.
The way to solve this is by cooperation, not by staying aloft and
pointing the finger to the opposite side.
I didn't intend to ask that fbdev change their licence (although I wish
they would). I merely intended to point out that, however much the fault
was mine, the perception of the licence conflict had blocked transfer
from fbdev to XFree86.
Well, i believe this was not the only issue involved. And i guess that
if the XFree86 Project was asking the fbdev people that they move to a
dual licence or something such, in order to better share information and
code between the fbdev drivers and the XFree86 drivers, then
undoubtfully this would have happened, with the natural problem of
searching for non-active authors of past code. I believe that Benjaming
Herrenschmidt raising its concern about driver code consecutive to the
announcement of the XFree86 licence could
Re: [forum] [XFree86] Announcement: Modification to the base XFree86(TM) license.
, if this is not the case, it can be solved in various ways. One way would be to declare that the files affected by the XFree86 licence change will not apply to those libraries, this is probably the easiest thing to solve this problem, and people wanting to reuse code from the rest of the XFree86 code base, well they either may reach an agreement with the respective copyright holder, or not use it, but it will not be as problematic as the library issue is. Another pair of solutions, but i am no lawyer and it should be double checked, would be to either : a) change the clause 3) in such a form that it does no more conflict with the GPL. I belive that there are ways to give the aknowledgement without GPL compatibility problems, or maybe make the enduser aknoledgement not obligatory, but something considered polite or such. And i have recently been told by the debian-legal folk that we should be polite to RMS with regard some emacs file distribution issues, which should also play here. or b) Clarify what we consider a derivative work, and make it clear that the further restrictions is not supposed to cross the library-application dynamic linking barrier. Or maybe add a phrase to the effect that if a GPLed application or library is linked with the XFree86 libraries, then the clause 3), which would conflict with the GPL is not needed to be enforced, but we would be really happy if it still does, or something such. Again with the caveat of clarification with the clause 3). Notice that this is informal speak, and i would be happy to propose a more formal wording of this in case it is needed, if we decide to pursue this solution. If that is done, then i believe all this mini-crising that has been brewing since the past days, will fall to the side, and everyone will be happy. 5) What about hardware drivers ? Now let's come back quickly to the problem of the hardware drivers, which are mostly the graphic chip drivers, but could also be concerning motherboard chipsets (like the agpgart stuff) or input drivers. This is a critical problem not only for XFree86, but also for all projects which touch these areas, among them most prominently the linux fbdev project. Now, mostly the information that goes from the XFree86 project in these areas to the fbdev driver is simple register level information which cannot be copyrighted anyway, and would cause less of a problem if the hardware companies would not retain this information, and thus actively oppose in some way the development of free alternatives. This is an area which is not problematic in the same area in which the library situation is, since mostly the drivers are copyrighted by their own authors, and the licence has not been changed. There has been some critics that the code can flow only in one side (X - linux fbdev) because of the linux GPL licence, but this is not the case, and something where cooperation could solve all perceived problems. Ideally, the code in question on the X side would remain on the old X licence, and the linux fbdev code would be on a dual GPL-old X licence. Or the fbdev folks may give changes and improvement back to XFree86 under the old X licence, or whatever. Problematic is naturally old code where lot of people contributed, and where some of those contributors disappeared from the circulation. So, this is basically no problem, if people on both side seek a compromise, and act in good faith. Ok, that is all i had to said, i hope i have properly analysed the problems that result from the licence change, and showed path that could lead to the resolution of said problems. Friendly, Sven Luther ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [Linux-fbdev-devel] Re: [forum] Re: Announcement: Modification to the base XFree86(TM) license.
On Sat, Jan 31, 2004 at 09:10:22AM +, Andrew C Aitchison wrote: On Fri, 30 Jan 2004, Sven Luther wrote: Yeah, that would be rather problematic, but anyway, most of the things move from the XFree86 code to fbdev code, and most often, it is not code that is copied, but the register information and such. It is always easier to get specs if you are working for XFree86 than if you plan to do some kernel driver work. On Sat, 31 Jan 2004, Benjamin Herrenschmidt wrote: The fact that it is mostly a one way is mostly due to the fact that the main problem here is seeking for HW informations. For several years the mga fb kernel driver has supported dual head and/or dvi on cards which aren't supported by the XFree86 driver (unless you use the mga_hal). I've wanted to use kernel code to add this support to XFree86, but been put off by the licence problem. And, have you asked the mgafb driver author about this ? You can hardly complain about lack of back traffic if you didn't ask him about it, and if you did, it would be interesting to this discussion to know what the problems where. As I remember it, the pertinent register information here was reverse engineered, so it is at least arguable that I'd be copying fbdev intellectual property here if I'd extracted and reused it. Perhaps I was wrong, but my understanding from my days in a software house taught me that I'd be breaking copyright not just by lifting lines of code, but also by reading the code and copying intellectual property, including register information. Yeah, sure. Which is way you ask for getting a licenced copy you can use or something. I guess that this will be much more likely to happen from a kernel fbdev driver author than from a commercial entity, will it not ? Besides there are only a few ways of writing code to twiddle a bit in a register - I could easily duplicate a line of code while reconstructing it from the register description, and it would be hard to prove that I didn't just copy the line directly. I doubt that this kind of stuff is possible to fall under copyright, or else the copyright law is more broken than i thought. I know that a bunch of C header files, with only datastructures and functions declarations cannot be copyrighted. So, for one developer at least, the reason there has been no traffic from fbdev to XFree86 is *directly* because of the licence issue. Yeah, but again, was it so because of a definite will on the fbdev authors part, or because you didn't ask him ? Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Manufacturers who fully disclosed specifications for agp cards?
On Sat, Jan 31, 2004 at 04:43:17PM +0200, Shaul Karl wrote: Excluding Nvidia and ATI, for which I believe I know the answer, what manufacturers I am likely to see on ebay that: 1) Usually fully and freely publish the specifications of their AGP hardware. 2) Got themselves an X driver? As of the time of this writing, http://search.ebay.com/ws/search/SaleSearch?from=R8ht=1satitle=video+cardsokeywordredirect=1sosortproperty=1sacategory=40156catref=C1 has the following: Other (707) Matrox (82) Diamond (61) S3 (57) 3DFX (51) ASUS (29) STB, Visiontek (21) I am looking for a used old agp card. 3Dlabs older cards also work pretty well. The 3D accel is not fully working though, except for the GMX2000, but i don't know if that good is well maintained still. 3Dlabs cards with gamma chip have the potential to be of geforce 1/2 speed with regard to 3D. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [forum] Re: Announcement: Modification to the base XFree86(TM) license.
On Fri, Jan 30, 2004 at 11:50:40AM +1100, Benjamin Herrenschmidt wrote: On Fri, 2004-01-30 at 03:58, David Dawes wrote: Announcement: Modification to the base XFree86(TM) license. After a thorough re-examination of the XFree86(TM) license and reviewing how it fits in with the Project's long-stated licensing philosophy (You can do what you like with the code except claim that you wrote it.), The XFree86 Project, Inc. has made some changes to its base license. This license review was prompted by a desire to ensure that XFree86 and its contributors are receiving due credit for their work. The text of the modified license can be found at http://www.xfree86.org/legal/licenses.html. .../... Hi David ! I'm no license/legal expert, but do that mean the licence becomes GPL incompatible ? In that case, that basically means you are screwing up any effort to make a decent graphics driver model in the linux kernel. Benjamin: Notice that this only applies to code marked as copyrighted by the XFree86 project, and supposedly, the actual driver code is mostly copyrighted by their respective authors, i doubt the graphic card companies would want to give away the copyright on the code they write, and i know the driver i wrote has myself as copyright. As thus, i doubt this will have any influence in your particular case. As for the GPL incompatibility, It would need proper checking, but i think David believes there is no problem, altough many people claim the contrary (Saying that the even Apache recently changed their licence because of this incompatibility). That said, this would really be a problem only for the libraries, so maybe it would b best to have a more lenient licence for the libraries (how much of them are copyrighted by the XFree86 project anyway, most should be comming from X.org, no ?), while keeping this licence for the X server propper, and whatever the actual authors chose for the drivers, or probably the old licence. I believe that this will serve the aim of showing proper credit, without causing problems to fbdev driver writers, which use the XFree86 driver source as documentation for chipset programing specs, and without causing any interoperability problems with libraries, without having to walk done the 'system library' clause of the GPL. David, what do you (and other involved with this decision) think about this ? Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [forum] Re: Announcement: Modification to the base XFree86(TM) license.
On Fri, Jan 30, 2004 at 05:19:03PM +0100, Egbert Eich wrote: Benjamin Herrenschmidt writes: Losing the ability of porting code straight from these to the fbdev drivers will basically kill all my efforts to turn the kernel radeonfb into a decent driver as I need to be able to re-use the code ATI puts in the XFree version. I suppose the same will happen to linux rivafb. Relating to that: exchanging code between XFree86 and kernel has been a one-way road so far. The GPL the kernel is under doesn't allow us to port back improvements that have been made to the kernel to our drivers Even though this isn't covered by the GPL the author of the driver or the changes could still give the permission to do so. I whish there was a better exchange between kernel fbdev developers and driver developers here. Maybe a decision on both parts on this would be ok ? XFree86 could make sure the licence of the driver code would not conflict with the GPL, keeping the old one for example, and the fbdev driver authors would dual-licence the code, both GPL and the old xfree86 licence would do just fine. Benjamin, what do you think about this ? BTW, CCing this to the linux-fbdev mailing list. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Linux-fbdev-devel] Re: [forum] Re: Announcement: Modification to the base XFree86(TM) license.
On Fri, Jan 30, 2004 at 08:25:40PM +0100, Egbert Eich wrote: Sven Luther writes: Maybe a decision on both parts on this would be ok ? XFree86 could make sure the licence of the driver code would not conflict with the GPL, keeping the old one for example, and the fbdev driver authors would dual-licence the code, both GPL and the old xfree86 licence would do just fine. Benjamin, what do you think about this ? BTW, CCing this to the linux-fbdev mailing list. Yes, a personal agreement between driver developers would also work. However they tend to change and other people will make contributions who all would have to agree also. I don't know if a general dual license agreement in the kernel file header would be possible. Also it could get removed once the author changes. Just like the license in the XFree86 driver could be amended. I guess already some drivers have such a dual licencing. Doing this now for existing fbdev driver would involve to ask anyone who has contributed little more than a typo fix. Yeah, that would be rather problematic, but anyway, most of the things move from the XFree86 code to fbdev code, and most often, it is not code that is copied, but the register information and such. It is always easier to get specs if you are working for XFree86 than if you plan to do some kernel driver work. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: -rpath not used under Linux
On Fri, Jan 23, 2004 at 05:43:02PM -0500, David Dawes wrote: On Wed, Jan 21, 2004 at 12:34:17PM +0100, Gian Filippo Pinzari wrote: David Dawes wrote: I don't have any objections to doing this on Linux. As I said, we already do it on a range of other platforms and I'm not sure why Linux is something of an exception in this regard. Does anyone have a good reason to not do this? In NX we use alternate versions of libX11, libXext and libXrender. This is done in a way that doesn't interfere with the existing X client environment, by setting LD_LIBRARY_PATH and, sometimes, LD_PRELOAD, before running the involved application. Probably the same applies to other systems built on top of X11. The use of -rpath is not going to compromise this possibility and I would consider this OK. Anyway, as a rule of thumb, I would prefer a system where the only libraries that are used are those listed in ld.so.conf. A specific application could still override the system settings. Such application might wish to do so in order to coexist with an alternate setup (think at two different versions of KDE or GNOME installed on the same computer). Having applications defaulting to a hardcoded library path could be a nightmare. I would really prefer to deal with a program failing with an unre- solved symbol instead of one dumping its core in the background for no apparent reason. So long as ld.so.conf overrides the rpath (does it?) then this won't matter. LD_LIBRARY_PATH and LD_PRELOAD won't work for setuid apps. I'd be happy to make the change for 4.4 if there is some concensus that it isn't a bad thing to do, and providing that ld.so.conf provides a mechanism for overriding the rpath. If you do that, i can guarantee you that all distributions will patch it to restore the previous -rpath less behavior. I guess that -rpath is only usefull for some installation in strange places where one doesn't want to modify the ld.so.conf file or something, or perhaps user built libraries ? Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: -rpath not used under Linux
On Sat, Jan 24, 2004 at 10:31:21AM -0500, David Dawes wrote: So long as ld.so.conf overrides the rpath (does it?) then this won't matter. LD_LIBRARY_PATH and LD_PRELOAD won't work for setuid apps. I'd be happy to make the change for 4.4 if there is some concensus that it isn't a bad thing to do, and providing that ld.so.conf provides a mechanism for overriding the rpath. If you do that, i can guarantee you that all distributions will patch it to restore the previous -rpath less behavior. Since ld.so.conf does not overriede -rpath, it won't be added for Linux. Yeah, i read it in another thread, but i just wanted to warn you about this. I maintain the debian ocaml package, and some stuff there did also set the rpath, and the concensus when i asked about this was that rpath is evil, and should never be used (altough some argued the opposite). Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Debian
On Thu, Jan 22, 2004 at 05:12:28PM -0500, Michael Taylor wrote: Marc Aurele La France wrote: This came up while helping some clueless Windows exile(e): So, how come Debian stable is still at XFree86 4.1? Because that is what they had in 'testing' when they released Debian 3.0r0 (woody) back in July 2002. Currently their 'testing' aka sarge has XFree86 4.2.1 Well, woody was frozen in early 2002, and scheduled to be released in april/may, but the actual release was delayed for putting up the security infrastructure needed to build security updates on all supported arches. plus patches (...-12.1) which is scheduled to be made their 'stable' release possibly in Feburary I believe. Err, i think that 4.3.0-1 will go into unstable soon, and will probably be the one which will go in the next debian release. Only sparc and s390 packages are missing, and sparc will be built soon. I don't know if we will wait for s390. Debian's Changelog for XFree86 4.2.1 http://packages.debian.org/changelogs/pool/main/x/xfree86/xfree86_4.2.1-12.1/changelog Also of interest : http://necrotic.deadbeast.net/xsf/XFree86/NEWS.xhtml and particularly this NEWS item : [20 January] A link to the TODO file for upload of XFree86 4.3.0-1 to Debian unstable has been added to the links above. As of this writing, all that remains is completion of the patch audit. Nathanael Nerode has been helping out tremendously with this. When 4.3.0-1 is finally uploaded, be sure to include him in your thank-you it's-about-damn-time messages. I don't understand the Debian policy but it would be nice if at least 4.3.0 was included in their release of sarge as stable next month. A debian/sarge release next month would most assuredly be premature. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Debian
On Fri, Jan 23, 2004 at 10:51:24AM -0500, Michael Taylor wrote: Sven Luther wrote: On Thu, Jan 22, 2004 at 05:12:28PM -0500, Michael Taylor wrote: I don't understand the Debian policy but it would be nice if at least 4.3.0 was included in their release of sarge as stable next month. A debian/sarge release next month would most assuredly be premature. My (limited) understanding is that there plan to release a new stable in 2004, with the goal of being sooner than later. Is this correct? Yeah, sure. What version of XFree86 will the new (future 2004) stable include 4.2.1 or 4.3.0? 4.3.0 naturally. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Disbandment
On Wed, Jan 14, 2004 at 10:49:12AM -0500, Thomas Dickey wrote: On Tue, 13 Jan 2004, Ruth A. Kramer wrote: Here's what it says at www.xfree86.org: quote No More Core Team [30 December 2003] The XFree86 core team has voted to disband itself, effective 31 December 2003. The XFree86 Project and its active cutting-edge developers are all still very much alive and residing in our development forum. Comments about this can be made there; registration is not necessary. The last I looked, no one had made any comments there. Has anyone tried? (anonymous postings in slashdot the like are worthless) The main point is, i think, to clearly say that if the core team as been disbanded, this doesn't touch XFree86 per see, and it is more a internal reorganisation or something such, and doesn't change anything with out relation with the outside. That said, i perfectly understand that these issues are quite puzzling for outside people, who mostly know XFree86 only from using it, but nothing of the internal quarrels we had in the past. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: How can we XGI share our Linux 2D driver with the open source community? Thanx
On Mon, Jan 12, 2004 at 08:22:50AM -0800, Alex Deucher wrote: Thank you for producing an opensource driver! Any possibility of a open source 3D driver down the road? even a lite version? Notice that this will give you an edge in todays conpetence, since neither NVidia nor ATI provide open source 3D drivers. If XGI was to release this, i can predict that the XGI cards may well become the graphic cards of choice of many Linux users (as well as other OSes supporting the DRI). Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
X problems on Marvel Discovery 2 based Pegasos 2 motherboard.
Hello, I have lately been working at porting the linux kernel to the Pegasos 2 motherboard (http://www.pegasosppc.com/tech_specs.php), which uses the Marvell Discovery 2 northbridge. Their site is currently down, but the web site should be : http://www.marvell.com/products/communication/discoveryII/MV64340.jsp Anyway, the discovery II posess two independent pci controllers, but also use the pci functions 0-5 or something such for not really pci-bridge conformant stuff. As a result, in the kernel i make the necessary things to either hide the pci controller, or just show enough information for it to be indentified. This works well with fbdev drivers, but X is less than happy about this. If i totally hide the device 0 pci configs (both read and write), X works well on radeons (altough using dri freeze after a few seconds on everything except the radeon 7500, but this is another issue, i think), but dies with the tdfx driver and voodoo 3 graphic cards. Also, in any case, i get the following message : (WW) INVALID IO ALLOCATION b: 0x1000 e: 0x10ff correcting^G Which i think may be linked to the problem, but i have not yet had time to go hunting for it in the sources. The tdfx driver further dies with : (EE) TDFX(0): No valid PIO address in PCI config space Any idea on where i should look ? Also, the motherboard contains a little magic thingy, which is supposed to transform one of the PCI buses into an AGP config space compatible bus, but which needs special treatment when reading or writing to the config space. I have the feeling that this is no problem, since on linux, XFree86 use the kernel facility to access config space. Anyway, i append the full log of the failed radeon case, where the marvell discovery bridge shows up. Any help on where to start to look would be welcome. BTW, this is with the debian 4.3.0-0pre1v5 X packages. Friendly, Sven Luther This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to [EMAIL PROTECTED] and patches submitted to [EMAIL PROTECTED] Before reporting bugs in pre-release versions, please check the latest version in the XFree86 CVS repository (http://www.XFree86.Org/cvs). XFree86 Version 4.3.0.1 (Debian 4.3.0-0pre1v5.1 20040107192252 [EMAIL PROTECTED]) Release Date: 15 August 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.23 ppc [ELF] Build Date: 07 January 2004 Before reporting problems, check http://www.XFree86.Org/ to make sure that you have the latest version. Module Loader present OS Kernel: Linux version 2.4.24 ([EMAIL PROTECTED]) (gcc version 3.3.3 20031229 (prerelease) (Debian)) #3 Tue Jan 13 10:22:42 CET 2004 Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/XFree86.0.log, Time: Tue Jan 13 10:45:05 2004 (==) Using config file: /etc/X11/XF86Config-4 (==) ServerLayout Default Layout (**) |--Screen Default Screen (0) (**) | |--Monitor Generic Monitor (**) | |--Device Generic Video Card (**) |--Input Device Generic Keyboard (**) Option XkbRules xfree86 (**) XKB: rules: xfree86 (**) Option XkbModel pc105 (**) XKB: model: pc105 (**) Option XkbLayout fr (**) XKB: layout: fr (==) Keyboard: CustomKeycode disabled (**) |--Input Device Configured Mouse (**) |--Input Device Generic Mouse (WW) The directory /usr/lib/X11/fonts/CID does not exist. Entry deleted from font path. (**) FontPath set to unix/:7100,/usr/lib/X11/fonts/Type1,/usr/lib/X11/fonts/Speedo,/usr/lib/X11/fonts/misc,/usr/lib/X11/fonts/cyrillic,/usr/lib/X11/fonts/100dpi,/usr/lib/X11/fonts/75dpi (==) RgbPath set to /usr/X11R6/lib/X11/rgb (==) ModulePath set to /usr/X11R6/lib/modules (--) using VT number 7 (WW) Open APM failed (/dev/apm_bios) (No such file or directory) (II) Module ABI versions: XFree86 ANSI C Emulation: 0.2 XFree86 Video Driver: 0.6 XFree86 XInput driver : 0.4 XFree86 Server Extension : 0.2 XFree86 Font Renderer : 0.4 (II) Loader running on linux (II) LoadModule: bitmap (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor=The XFree86 Project compiled for 4.3.0.1, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.4 (II) Loading font Bitmap (II) LoadModule: pcidata (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor=The XFree86 Project compiled for 4.3.0.1, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.6 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 11ab,6460 card 0020, rev 03 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 1106,3044 card 1106,3044 rev 46 class 0c,00,10 hdr 00 (II) PCI: 00:05:0: chip 1000,0001 card 1000,1000 rev 23 class 01,00,00 hdr 00 (II) PCI
Re: State of radeon driver
On Wed, Dec 10, 2003 at 01:44:23PM +0100, Alexander Stohr wrote: I have tried these drivers but refuse to work. They think I have an (unsupported) OEM card (=powered by ATI) while according to the identity check programs run under XP it 'should' be an ATI one (=Built by ATI) There is no general OEM barrier anymore. It only was it was in early days where no one was sure if drivers would work well on those boards. It would be kind if you can you retry this test with latest fglrx drivers and mail me the results in private or public, just as you want. Any chance for getting a powerpc build of them, for the nice new powerbooks with mobility 9600 graphic card in it ? Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: nv driver obscurities...
On Sun, Nov 09, 2003 at 11:23:38AM -0800, Alex Deucher wrote: I agree that with hex values the driver is much harder to read and debug (as a casual developer). that's part of the reason the radeon driver is so well developed and feature-rich. however, I'd say that most drivers in xfree86 use hex values rather than symbolic names so symbolic names are hardly the norm. the nv driver is no more obscured than the trident or 3dlabs, etc. drivers. Have you looked at the glint driver ? All the register are accessed using nice named macros, taken out of the corresponding documentation. Or are you speaking about another 3dlabs driver i don't know about ? Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: nv driver obscurities...
On Mon, Nov 10, 2003 at 06:38:24AM -0800, Alex Deucher wrote: Sorry I haven't looked at the glint driver in a while. I was just trying to make a point that lots of drivers out there use hex rather than symbolic names. I seemed to recall glint as being one of them, but I guess I was wrong. Maybe the old 3dlabs XFree86 3.3 server was in this case, but the glint driver has had nice symbolic names since a long time. 3Dlabs is even quite free in releasing full NDAed documentation, unlike other companies. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Debugging XFree86 on a single machine
On Thu, Oct 02, 2003 at 10:33:58AM +0100, Dr Andrew C Aitchison wrote: On Wed, 1 Oct 2003, Kirk Haderlie wrote: Is it possible to debug XFree86 using a dual monitor setup on a single machine. I tried using -keeptty but this doesn't do what I would expect. Can X be run on one monitor and a debug console on the other? You need two video cards (as Andrew Bevitt mentioned). You must make sure that the server under test doesn't grab the keyboard or mouse from the debug console; giving it dummy devices with the void input device driver (you could use a second mouse but I've never got a second keyboard to work with 2.4.small kernels). All in all, telnet/ssh from a second machine is usually less hassle. BTW, how do you make it so that X doesn't blank the console on the other head ? Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Debugging XFree86 on a single machine
On Thu, Oct 02, 2003 at 04:00:24PM +0100, Dr Andrew C Aitchison wrote: On Thu, 2 Oct 2003, Sven Luther wrote: BTW, how do you make it so that X doesn't blank the console on the other head ? My memory is going - it is a long time since I tried this, and I'd forgotten about the that. It is the main problem and I've never solved it. No wonder I pefer telnet/ssh. Yep, that is indeed the main problem. Linux 2.5 (possibly back ported to 2.4.large) allows consoles on multiple heads. I've seen reports that that allows two servers to run. Presumable that allows debugging. Mmm, i think i heard on the linux-fbdev list that it was post 2.6 stuff, and i think the reports you heard about where mostly hacks. Anyway, i want two different seats on both heads of one graphic card, which is not possible anyway (altough could be with my Jeronimo 2000, as it has two separate rasterizer chips driving each head). Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 SDK
On Mon, Sep 08, 2003 at 04:58:22PM +0100, Paul Nasrat wrote: I've been doing some work building drivers using XFree86 sdk, and here are a few things I've noticed. Hello, ... I have been working on this selfsame thing, but alas have not had time to do much work on this, but i will look at it again this WE. In order to package a driver snapshot, I had to modify the INCLUDES to be an absolute path as I wasn't doing it within the sdk tree. Mmm. The SDK as it currently stands doesn't survive well if you move it around, and the selfsame problem happens if you use drivers sources from another source than the SDK. From the nightly drivers CVS snapshots for example. I was wondering would it be worth having a variable that gets expanded by imake to the XFree86 sdk root so rather than having #if defined(XF86DriverSDK) INCLUDES = -I. -I../../include #else ... standard includes it would be better to say something along the lines: INCLUDES = -I. -I$(XF86DriverSDKTop)/include Mmm, Yep, that would be nice, especially if you can later override the XF86DriverSDKTop variable to build anywhere. this would make it easier for packagers as they can just set the value with a define rather than having to patch each driver they want to build out of tree (eg for testing newer driver versions). The imake command I used (I built the ati driver amongst others) was: Did you use the CVS ati driver with the CVS SDK, or the CVS ati driver with the 4.3.0 SDK ? imake -I/usr/X11R6/lib/Server/config/cf -DUseInstalled -DXF86DriverSDK Yep, this is something i was aiming at. More of this this weekend. Also I've been experimenting with building some larger projects which tend to need a full XFree86 source tree with the sdk. This is going quite well, but there is some way to go before building a whole Xserver (eg vnc) is possible. What is the general feeling about enriching the XFree86 SDK to more than just graphics drivers? I think egbert is working on a redesigned SDK, maybe such projects would fall better in such a framework. I myself am not so favorable to it, unless we build a two level SDK. One would be called DDK and be only for drivers, the standard SDK would build depend on it and provide functionality for more stuff. The Driver SDK needs to be kept small enough to enable people to easily rebuild drivers with it. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xfree86, DRI, and multiple heads: thoughts and ideas
On Thu, Aug 28, 2003 at 07:31:08AM -0700, Alex Deucher wrote: Dualhead... Right now there is dualhead support for the following cards in xfree86: radeon matrox sis via chips 3dlabs (Sven mentioned that he had this quasi-working on the newer cards, although I don't know the state of his driver) Well, the driver is blocked in no-accel state for the wildcat VP 560, this would be no problem for implenting the dual head thing in a merged fb. I have not been doing much work on it lately, and there are still some Issues with dual head when one head is DVI connected. My current XFree86 work has to do with the SDK, but i had not had as much time as i wanted for this too. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xfree86 for the VIA Apollo CLE266
On Fri, Aug 08, 2003 at 03:53:00PM -0400, David Dawes wrote: On Fri, Aug 08, 2003 at 10:14:58AM +0200, Sven Luther wrote: On Fri, Aug 08, 2003 at 02:21:28AM -0400, David Dawes wrote: On Fri, Aug 08, 2003 at 06:41:58AM +0200, Sven Luther wrote: On Thu, Aug 07, 2003 at 04:52:02PM -0400, David Dawes wrote: On Wed, Jul 30, 2003 at 06:50:28PM -0400, George Georgalis wrote: On Tue, Jul 29, 2003 at 11:59:06PM -0400, David Dawes wrote: On Tue, Jul 29, 2003 at 09:37:06PM -0400, George Georgalis wrote: I heard (second hand from via) that xfree86 2.3.99 has drivers for the CLE266 ( http://www.via.com.tw/en/apollo/cle266.jsp on a http://www.viavpsd.com/product/epia_m_spec.jsp?motherboardId=81 ) I got the cvs source this morning and it built without errors on my fast box. It's been compiling (for a while now) on the hardware I plan to run it from. I assume all will be okay. Here's my next question. After poking around in the source I found ./programs/Xserver/hw/xfree86/drivers/via/ Lots of good stuff in that directory for making the CLE266 work... only how do in invoke it and confirm it's being run? It's confusing to me how a program (eg mplayer) would know to use xfree (and the cle266) for mpeg-2 decoding and not just do the decoding on its own. 4.3.99.9 has a known build problem (which you're seeing). Either try 4.3.99.8, or get the latest code via anoncvs. Humm, a README in that directory could contain note to that effect? or the changelog could be reissued for that file? Thanks for the fast responce anyhow. These are automatically generated code snapshots and nothing more. If you look at http://www.xfree86.org/develsnaps/ you'll see that there is no guanrantee that any given snapshot will build or run. BTW - how do I tell what version of cvs I got? Assuming you checked out the trunk (which is the default), you got the lastest development code as of the time you checked it out. The version is something later than the previous snapsnot. What about marking the version as 4.3.99.x for the snapshot, and once it is released, mark the version as 4.3.99.x+ or 4.3.99.x+co date for the CVS versions, until a new snapshot is taken. Maybe it could only be done in the XFree86.0.log output code, and not the actual version be changed. I usually update the date in xf86Date.h when committing. That gives some indication, and is printed on the line after the version in the log file. I don't think it matters that much personally, but if I wanted to achieve something like this for my own checkouts, I'd use a script that did something like this: #!/bin/sh date=`date` cvs co xc echo #undef XFree86CustomVersion xc/config/cf/host.def echo #define XFree86CustomVersion \$date\ xc/config/cf/host.def I'm not sure how you'd make cvs automatically create a reliable date for all possible ways of checking out the source. Using a CVS date variable or something such, which the XFree86CustomVersion would be set to when taking it out of CVS, and which you would remove before doing the snapshots ? Do you have a specific example? Preferrably one that doesn't unnecessarily complicate things. Err, i was thinking of putting an #define XFree86CustomVersion $Date per default in one of the .cf files, and erase this lines when doing the export for the snapshots. Either by hand after having done the export, or with a special option to cvs export. I believe you would have to use another variable ($CheckoutDate ?) which you would usually have set to $Date, and which you would then set to nothing when doing the export. I believe there is a cvs option that can override one of the keyword expansions, but i am not familiar enough with cvs to tell you which, and if it doesn't work, it can be done by hand. Now, the problem is probably that the $Date will give a string prefixed by the $Date: string, and include the hour probably also, so maybe some kind of postreatment is needed, but i don't know if it is feasible in cpp. It was just an idea anyway. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xfree86 for the VIA Apollo CLE266
On Sat, Aug 09, 2003 at 12:32:02PM -0400, David Dawes wrote: On Sat, Aug 09, 2003 at 05:41:25PM +0200, Sven Luther wrote: On Fri, Aug 08, 2003 at 03:53:00PM -0400, David Dawes wrote: On Fri, Aug 08, 2003 at 10:14:58AM +0200, Sven Luther wrote: Using a CVS date variable or something such, which the XFree86CustomVersion would be set to when taking it out of CVS, and which you would remove before doing the snapshots ? Do you have a specific example? Preferrably one that doesn't unnecessarily complicate things. Err, i was thinking of putting an #define XFree86CustomVersion $Date per default in one of the .cf files, and erase this lines when doing the export for the snapshots. Either by hand after having done the export, or with a special option to cvs export. I believe you would have to use another variable ($CheckoutDate ?) which you would usually have set to $Date, and which you would then set to nothing when doing the export. I believe there is a cvs option that can override one of the keyword expansions, but i am not familiar enough with cvs to tell you which, and if it doesn't work, it can be done by hand. I don't think it is either necessary or desirable to make exceptions for snapshots. Snapshots are defined simply by tags, and not by the way they are later checked out or exported. Yep, manual manipulation is not nice and will most assuredly cause mistakes some days or others. Now, the problem is probably that the $Date will give a string prefixed by the $Date: string, and include the hour probably also, so maybe some kind of postreatment is needed, but i don't know if it is feasible in cpp. It was just an idea anyway. Well, I asked for a specific example because I can't think of one that will give consistent results without intruding on the commit process. The problem with $Date is that it expands to the commit date of the file, not the checkout date (or the -D date). If there was a Effectively, i didn't think of that. This would not work i guess. solution like this, it could go in xf86Date.h, and it wouldn't require exceptions for the snapshots/releases. What about using the date of the CHANGELOG file ? The only thing I can see that would give a consistent and predictable result in all cases (cvs co, cvs co -D date, cvs -r tag) would be to have xf86Date.h automatically modified with every single commit. This wouldn't be the checkout date, but a date representing the last commit in the checked out tree. The only ways I can think of doing that right now would cause more inconvenience than I think it's worth, but if someone has a specific tested solution, with documented impact and side-effects, let me know. Alternatively, we could use the almost same effect by somehow having the XFree86.0.log include the latest CHANGELOG entry number. This could be done by some preprocessing. If the date in the first XFree86 line is full, and we have a normal release, or it is marked as xx or some other sign, and we are facing a CVS checkout. In this case, we use the first number in the line just below the XFree86 line, and embed that number in the log message writing code. A little sed or awk or whatever processing in the Imakefile should produce the desired effect at build time. This would enable us to easily spot when the tree was checked out, and would not need us to fool with CVS stuff or so. Naturally this supposes that the CHANGELOG file is updated regularly between comits, but this is the case anyway. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Post-processing X-server output
On Thu, Aug 14, 2003 at 11:07:46AM +0200, Alexander Block wrote: Thanks for your quick answer. Where can I get more information about the shadowfb driver (include file, library, API doc) ? In the X source file ? I don't know if the design document speaks about it, but it is rather straightforward to implement. The source code of shadowfb is in : xc/programs/Xserver/hw/xfree86/shadowfb And contain the following header file : /* $XFree86: xc/programs/Xserver/hw/xfree86/shadowfb/shadowfb.h,v 1.4 * 2003/02/18 19:10:35 alanh Exp $ */ #ifndef _SHADOWFB_H #define _SHADOWFB_H #include xf86str.h /* * User defined callback function. Passed a pointer to the ScrnInfo * struct, * the number of dirty rectangles, and a pointer to the first dirty * rectangle * in the array. */ typedef void (*RefreshAreaFuncPtr)(ScrnInfoPtr, int, BoxPtr); /* * ShadowFBInit initializes the shadowfb subsystem. refreshArea is a * pointer * to a user supplied callback function. This function will be called * after * any operation that modifies the framebuffer. The newly dirtied * rectangles * are passed to the callback. * * Returns FALSE in the event of an error. */ Bool ShadowFBInit ( ScreenPtr pScreen, RefreshAreaFuncPtr refreshArea ); /* * ShadowFBInit2 is a more featureful refinement of the original * shadowfb. * ShadowFBInit2 allows you to specify two callbacks, one to be called * immediately before an operation that modifies the framebuffer, and * another * to be called immediately after. * * Returns FALSE in the event of an error */ Bool ShadowFBInit2 ( ScreenPtr pScreen, RefreshAreaFuncPtr preRefreshArea, RefreshAreaFuncPtr postRefreshArea ); #endif /* _SHADOWFB_H */ If you need additional info, look at how the other drivers implement it. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Xrender transforms...
On Sun, Aug 10, 2003 at 05:59:54AM +0100, Alan Hourihane wrote: On Sun, Aug 10, 2003 at 02:27:13PM +1000, Carsten Haitzler wrote: Would I be correct in the assumption that the only accelerated path for xrender is the identity transform (1:1 scale)? all other transforms are done in software? (my initial tests here with xfree86 4.3.0 nvidia's latest drivers (as of about a month ago) seem to indicate as much...) (and yes... my drivers are using acceleration... GL definitely is). ? No. About 99% of the drivers don't have any xrender acceleration. I think only the mga driver does. Although looking furthur the sis has some, but it seems disabled, and the vmware driver has it too. But that's it. I guess nvidia do some acceleration in their binary drivers though, as you've probably found. But it's bad to assume other drivers have xrender acceleration. I think the thing that's holding other drivers up in getting furthur xrender acceleration is that there's no test suite to check that the driver is doing the right thing. I think Keith Packard mentioned he had intern's working on a test suite a while ago, but nothing has materialized as far as I know. And there is no documentation whatsoever on what to do. And Keith has been telling me each time i asked him that render was not yet ready and that i should wait. Last time was a year or so ago though, so ... Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xfree86 for the VIA Apollo CLE266
On Thu, Aug 07, 2003 at 04:52:02PM -0400, David Dawes wrote: On Wed, Jul 30, 2003 at 06:50:28PM -0400, George Georgalis wrote: On Tue, Jul 29, 2003 at 11:59:06PM -0400, David Dawes wrote: On Tue, Jul 29, 2003 at 09:37:06PM -0400, George Georgalis wrote: I heard (second hand from via) that xfree86 2.3.99 has drivers for the CLE266 ( http://www.via.com.tw/en/apollo/cle266.jsp on a http://www.viavpsd.com/product/epia_m_spec.jsp?motherboardId=81 ) I got the cvs source this morning and it built without errors on my fast box. It's been compiling (for a while now) on the hardware I plan to run it from. I assume all will be okay. Here's my next question. After poking around in the source I found ./programs/Xserver/hw/xfree86/drivers/via/ Lots of good stuff in that directory for making the CLE266 work... only how do in invoke it and confirm it's being run? It's confusing to me how a program (eg mplayer) would know to use xfree (and the cle266) for mpeg-2 decoding and not just do the decoding on its own. 4.3.99.9 has a known build problem (which you're seeing). Either try 4.3.99.8, or get the latest code via anoncvs. Humm, a README in that directory could contain note to that effect? or the changelog could be reissued for that file? Thanks for the fast responce anyhow. These are automatically generated code snapshots and nothing more. If you look at http://www.xfree86.org/develsnaps/ you'll see that there is no guanrantee that any given snapshot will build or run. BTW - how do I tell what version of cvs I got? Assuming you checked out the trunk (which is the default), you got the lastest development code as of the time you checked it out. The version is something later than the previous snapsnot. What about marking the version as 4.3.99.x for the snapshot, and once it is released, mark the version as 4.3.99.x+ or 4.3.99.x+co date for the CVS versions, until a new snapshot is taken. Maybe it could only be done in the XFree86.0.log output code, and not the actual version be changed. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: what parts of fb driver are used when Option USeFBDev is specififed?
On Tue, Aug 12, 2003 at 01:26:11PM -0500, Andreakis, Dean (MED) wrote: From a functionality point of view, what is the difference between using Option UseFBDev and using the fb device driver directly via Driver fbdev in XF86Config? Specifically, in the case where I specify Driver radeon and Option UseFBDev exactly what parts of the radeon fb driver are used instead/in place of the XFree86 radeon driver? Whats the diff between this and just specifying Driver fbdev directly? using a standard driver (like the radeon driver) with the UseFBDev option, uses the underlying fbdev for things like memory and mmio area detection, and for mode initialization and switching. The rests of it, including the accel engine, the video overlay and the 3D stuff is done with the radeon driver. When you use the fbdev driver, not only do you use the fbdev for detection and mode initialization, but you drive directly to the framebuffer memory, possibly using shadowfb to speed things up. There is no accel, nor video overlay possible though. I hope i did not leave anything out, and that this respond to your question. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xfree86 for the VIA Apollo CLE266
On Sat, Aug 09, 2003 at 03:02:51PM -0400, David Dawes wrote: On Sat, Aug 09, 2003 at 08:43:55PM +0200, Sven Luther wrote: Nice. But that would mean not using a xxx as day of the month as is currently done (or was last i checked out the tree). No, it gets it from the '$XFree86' line at the end. For the current CVS trunk, CLOG_DATE gets defined to 20030808, and the following is printed when you run 'XFree86 -version': XFree86 Version 4.3.99.9 Release Date: 8 August 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: FreeBSD 4.4-RELEASE-p1 i386 [ELF] Build Date: 09 August 2003 Changelog Date: 08 August 2003 Ok. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xfree86 for the VIA Apollo CLE266
On Fri, Aug 08, 2003 at 02:21:28AM -0400, David Dawes wrote: On Fri, Aug 08, 2003 at 06:41:58AM +0200, Sven Luther wrote: On Thu, Aug 07, 2003 at 04:52:02PM -0400, David Dawes wrote: On Wed, Jul 30, 2003 at 06:50:28PM -0400, George Georgalis wrote: On Tue, Jul 29, 2003 at 11:59:06PM -0400, David Dawes wrote: On Tue, Jul 29, 2003 at 09:37:06PM -0400, George Georgalis wrote: I heard (second hand from via) that xfree86 2.3.99 has drivers for the CLE266 ( http://www.via.com.tw/en/apollo/cle266.jsp on a http://www.viavpsd.com/product/epia_m_spec.jsp?motherboardId=81 ) I got the cvs source this morning and it built without errors on my fast box. It's been compiling (for a while now) on the hardware I plan to run it from. I assume all will be okay. Here's my next question. After poking around in the source I found ./programs/Xserver/hw/xfree86/drivers/via/ Lots of good stuff in that directory for making the CLE266 work... only how do in invoke it and confirm it's being run? It's confusing to me how a program (eg mplayer) would know to use xfree (and the cle266) for mpeg-2 decoding and not just do the decoding on its own. 4.3.99.9 has a known build problem (which you're seeing). Either try 4.3.99.8, or get the latest code via anoncvs. Humm, a README in that directory could contain note to that effect? or the changelog could be reissued for that file? Thanks for the fast responce anyhow. These are automatically generated code snapshots and nothing more. If you look at http://www.xfree86.org/develsnaps/ you'll see that there is no guanrantee that any given snapshot will build or run. BTW - how do I tell what version of cvs I got? Assuming you checked out the trunk (which is the default), you got the lastest development code as of the time you checked it out. The version is something later than the previous snapsnot. What about marking the version as 4.3.99.x for the snapshot, and once it is released, mark the version as 4.3.99.x+ or 4.3.99.x+co date for the CVS versions, until a new snapshot is taken. Maybe it could only be done in the XFree86.0.log output code, and not the actual version be changed. I usually update the date in xf86Date.h when committing. That gives some indication, and is printed on the line after the version in the log file. I don't think it matters that much personally, but if I wanted to achieve something like this for my own checkouts, I'd use a script that did something like this: #!/bin/sh date=`date` cvs co xc echo #undef XFree86CustomVersion xc/config/cf/host.def echo #define XFree86CustomVersion \$date\ xc/config/cf/host.def I'm not sure how you'd make cvs automatically create a reliable date for all possible ways of checking out the source. Using a CVS date variable or something such, which the XFree86CustomVersion would be set to when taking it out of CVS, and which you would remove before doing the snapshots ? Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Rant (was Re: ATI Drivers.)
more than to see all video hardware vendors release the specifications to their hardware openly to the public, as that would allow anyone to work on the driver code. However, with the current trademark, patent, and copyright system in place, companies out there want to protect what is theirs so it can't be used by competitors. They want to ensure they keep their technology that they've spent millions or billions of dollars developing in their own hands and not give it to competitors to use too. It's their decision what parts of their technology that they consider to be their assets and that they wish to keep as trade secrets. Again also, they license technology from other companies, either hardware and/or software, and the agreements they might possibly have with those 3rd party vendors very well may not legally allow them to provide information on how the hardware works, or to provide open source code to the community that allow that technology to operate. I don't understand why people find this so difficult to understand? Don't get me wrong, I would love to see all hardware out there have open source drivers, and see all vendors providing code and contributing fixes also, as well as providing complete technical specifications to all hardware. That would be a great utopia I would look forward to very much. The reality however is that we live in a capitalist society and have strict trademark/copyright/patent and trade secret laws designed to allow companies to invent/create something and then own it, either permanently, effectively permanently, or for some period of time. With this legal climate, this erects walls for open source, and they're not going to be easy walls to work around. We get what the lawyers say we can have basically, and we should be glad to get that, especially if the alternative is nothing. The problem is that we get what the US lawyer say we can, and not what we may very well have the right to in other places of the world. Not to count the free development time that goes into making the drivers work, or the amount of time one uses to answer about misguided proprietary nvidia drivers who have problems. They will not ask nvidia, but ask on the debian user list for example. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Rant (was Re: ATI Drivers.)
On Fri, Jul 18, 2003 at 12:44:46PM +0200, Peter Firefly Lund wrote: On Fri, 18 Jul 2003, Sven Luther wrote: Why do these companies not open source their complete drivers? Because they have intellectual property in their drivers that As if their concurent where not capable of reverse engineering the ^ competition A, i have been searching for this word a few times already this last week, thanks. somehow English chose another Latin word than the other Germanic languages -- the weirdness and hodge-podge nature of English strikes again :/ (this is not to spite Sven - merely to rant about English and at the same time increase the chances that an English-only speaker will understand) Well, it would also be nice if the english only speaker would maybe be a bit more open when encountering non native english with a few problems in the text. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
missing SDK includes ...
On Sat, Jun 07, 2003 at 07:50:53AM +0200, Sven Luther wrote: When discussing with Matthew, some other question came out, which need to be decided before we got further on this. Matthew tried to build the SDK without xlibs-dev, which i don't even considered doing. As such, he noticed 43 further headers which i did miss, and are part of the xlibs-dev header files. Two path can go from there : 1) We make the sdk depend on the xlibs-dev. Should be ok if the distribs distribute the SDK as part of the xfree86 packages. I am trying to obtain this from the debian packages. 2) We move those headers to the SDK and don't depend on the xlibs-dev. We need to make sure we use the headers from the SDK and never the usual ones though. As nobody responded to this, maybe it did not get noticed in the other mail. Debian is nearing a release of the 4.3.0 packages, which will include a SDK package, so i think it would be nice to solve this problem now, before all distributions implement the SDK in different ways. I hope to have this solved for this WE, when i will try to finish the SDK fix if we have reached a consensus. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: status of SiS 3d?
On Mon, Jun 02, 2003 at 09:51:00PM -0700, Alex Deucher wrote: --- Ian Romanick [EMAIL PROTECTED] wrote: I certainly wouldn't buy one to replace my Radeon 8500! :) It would be exclusively to update the drive. It's the same reason I would be a Gamma card w/an R2 rasterizer...too bad there are *none* on eBay. After I realized that, I pretty much give up any hopes of the gamma driver ever being updated. That is, unless 3dlabs were to give out documentation for an R3 or R4 rasterizer. I've heard 3dlabs is pretty good about giving out docs to driver developers, although that was before creative labs bought them. I know of two cases were they gave docs after creative labs bought them, so i think this did not change their policy very much. I may look into the gamma case once i get access to a motherboard supporting the agp 1/2x gamma+pm3 card i have again. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: SDK and drivers.
On Wed, Jun 04, 2003 at 06:02:15PM +0200, Egbert Eich wrote: Sven Luther writes: No problem, i have been busy with other things too, and my motherboard died on saturday, so i could not do much work this WE. I'm sorry to hear that. No problem, it was under guarantee :))) Also, would your new SDK still use a fixed path or should it be possible to install it anywhere ? Fixed path? I have not looked at the old SDK, but my plan is to have it like the build tree so you should be able to put it anywhere. Well, once you build and install the SDK, the PROJECTROOT gets expanded in the Imakefiles/Makefiles, and it has problem during the build phase if you moved it, since it tries to erase files in the old location, for which it may not have the rights. I was able to override this behavior by calling make wile overriding one of the make variables, i forgot which one right now, but i think it was something like USRINCDIR or something such. Ideally it would be easy to build in any place, possibly not as root, and then to be able to install as root, and with the install path accepting the $(DESTDIR) prefix, so the drivers can be installed into a package. My plan is to create a self-contained build environment which does not use any absolute paths but builds the stuff in directories relative to its root directory - much like the full build does. This sounds fine. But i guess it will be ready for the 4.4 timeframe, right ? I will continue hacking on the current SDK for 4.3 in the meantime. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: SDK and drivers.
On Mon, Jun 02, 2003 at 04:28:46PM +0200, Egbert Eich wrote: Sven Luther writes: On Tue, Apr 22, 2003 at 11:58:03AM +0200, Egbert Eich wrote: Sven Luther writes: Hello, ... I have been trying to build the driver SDK thingy on both 4.3.0 and head, and it seems to be somewhat broken. In particular there are some missing files, which altough needed, are not part of the SDK, like the render includes for example. So, i looked at the whole stuff, and have been trying to fix this, but encountered that many driver missed declaring some of their file, which is a pain. Since the driver SDK is aimed mostly at building drivers, maybe listing all files as being part of the SDK in the Imakefile is not the most appropriate way of doing this, since mostly _all_ the files of the driver directory are really needed, and in fact my aim is to not use the drivers from the sdk, but the ones from the driver module just announced by Alan. I'm currently exploring a toatlly new SDK which takes advantage of driver modules. It doesn't even attempt to add drivers to the SDK, but it expects them to be dropped in from a separate tarball. Hello, I expect to be looking at the SDK stuff again nextly, and would like to know if you did advance some with this code since you wrote this ? No, unfortunately not. I've just returned from vacation and didn't have time to look at it any more. The next two weeks are pretty occupied with other things, too. No problem, i have been busy with other things too, and my motherboard died on saturday, so i could not do much work this WE. Also, would your new SDK still use a fixed path or should it be possible to install it anywhere ? Fixed path? I have not looked at the old SDK, but my plan is to have it like the build tree so you should be able to put it anywhere. Well, once you build and install the SDK, the PROJECTROOT gets expanded in the Imakefiles/Makefiles, and it has problem during the build phase if you moved it, since it tries to erase files in the old location, for which it may not have the rights. I was able to override this behavior by calling make wile overriding one of the make variables, i forgot which one right now, but i think it was something like USRINCDIR or something such. Ideally it would be easy to build in any place, possibly not as root, and then to be able to install as root, and with the install path accepting the $(DESTDIR) prefix, so the drivers can be installed into a package. Friendly, Sven Luther Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: IBM port replicator noise?
On Thu, May 29, 2003 at 05:20:26PM -0700, Elliott Mitchell wrote: From: Michael B Allen [EMAIL PROTECTED] It is likely that the connector was only designed for 1280x1024 - which requires a smaller bandwidth. If the person with this problem is into hacking hardware he might try finding out which port replicator connector pins are used for DVI and whether the problem is interconnect within port replicator and/or interconnect within the notebook and/or noise from something else. I would also suggest trying to disconnect any other devices that might use port replicator connectors - especially USB ones. Well my dad's a TV repair man. Just kidding. Actually he is an EE and does a lot of DSP work (for which I've written a driver once) so your comments do interest me. Are you suggesting that the wires and connectors may just be too thin or made out of the wrong material and that creating a new connector between the laptop dock-out port to DVI-D in on the Monitor might be sufficient resolve the problem? I was under the impression it was a chip-output problem but that's pure speculation on my part. I wonder if I could even buy that male connector let alone identify it. PS: I found out the full-blown Docking Station II only supports low-profile PCI cards so that's out. So I'm basically wasting a 1600x1200 flat-panel (unless things get better with a DVI-A cable maybe). There are mentions of single link and dual link DVI-D cables. Originally I had been thinking that was for dual monitors, but the information I've got says that is for handling higher resolutions. Specifically with single link cables the limit is suposed to be 1280x1024, while dual link cables are suposed to handle 1920x1080. But i guess you loose dual head DVI-D output then, don't you ? That is, in such dual link cables, the two TMDS cooperate to send data trough one DVI-D connector only, thus doubling the bandwith, and you cannot use DVI on the second head ? But analog on the second head would work fine. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [forum] Help with configuration please!
On Tue, Apr 01, 2003 at 04:42:00PM -0500, Mark Vojkovich wrote: On Tue, 1 Apr 2003, Sven Luther wrote: On Mon, Mar 31, 2003 at 03:34:43PM -0500, Mark Vojkovich wrote: I stripped forum from the reply since devel is more appropriate. Ok, no problem with me. The reason why this doesn't work reliably in the nv driver is because there is not an I2C bus - there are THREE of them - and it's not clear which one the driver should be looking on. They're not One for each head ans one for the video port ? One for each head and another for other stuff, which can instead be on the first two in some cases. even the same between one card and the next since different board vendors can lay the cards out differently. If I know the correct bus, detection of the flat panel is trivial. This is a problem because you don't have full documentation, isn't it ? I have all the hardware documentation that I need, there's just too much variation in the board layouts to make assumptions about how things are laid out. I need to actually look for flat panels on all busses. The code to look for a panel on a bus is in the core server, but I'm not yet familiar with how to get it to run on multiple busses. I suppose this flat panel searching coe is not documented, right, where does it live, i have interest in this myself. I am looking into this problem, but I'm not familiar with XFree86's DDC code, and haven't found someone who is. This is probably because nobody really is, and because the DDC code is not really used right now. The standard open source reply is : you are interested in this ? you just have become the official expert on it. :) Yes, I'm aware of that. However, I am not yet an expert on it, so the problem is not yet solved. Currently, at least for the glint driver, the DDC/I2C info is read at ModeInit time, which is too late to do anything apart print the result of the edid read. The nv driver also does things a little to late to be useful. But there would be nothing wrong with doing it earlier in PreInit, i think. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [forum] Help with configuration please!
On Mon, Mar 31, 2003 at 03:34:43PM -0500, Mark Vojkovich wrote: I stripped forum from the reply since devel is more appropriate. Ok, no problem with me. The reason why this doesn't work reliably in the nv driver is because there is not an I2C bus - there are THREE of them - and it's not clear which one the driver should be looking on. They're not One for each head ans one for the video port ? even the same between one card and the next since different board vendors can lay the cards out differently. If I know the correct bus, detection of the flat panel is trivial. This is a problem because you don't have full documentation, isn't it ? I am looking into this problem, but I'm not familiar with XFree86's DDC code, and haven't found someone who is. This is probably because nobody really is, and because the DDC code is not really used right now. The standard open source reply is : you are interested in this ? you just have become the official expert on it. :) Anyway, the way i see it is that each driver should provide a DDC/I2C bus reading functions, which already exist, altough if i take example on the glint driver, it is filled at the end of PreInit, which is a bit late. Then, maybe before or during xf86ValidateModes, you would also call some monitor code, which would read information about the attached monitor of each head, and use the information to limit the possible available monitor modes, with a possibility to override this from the configuration file, if need be. Currently, at least for the glint driver, the DDC/I2C info is read at ModeInit time, which is too late to do anything apart print the result of the edid read. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
X server dying (seg 11) when cursor reaches bottom of the screen.
Hello, ... I am currently developping a new driver for a not yet supported graphic card. It used to work well as long as i was working with a mid January cvs snapshot, but i recently upgraded to 4.3.0 sources and built a driver from that, and since then i am experiencing X server crash when the mouse reaches the bottom of the screen. I did not encounter this problem before, nor does it appear when i use the vesa driver. My driver is currently unaccelerated and does not support HW cursor, i use shadowfb though (both with the driver and with the vesa driver). I tried running X trought gdb to get a bit more info, but it just froze the box, so i am a bit at a loss about finding what is going on, and would greatly appreciate some measure of help. The previous snapshot i was using did not seem to use the ARGB_Cursor thingy, and as the crashes happen when i bring the cursor to the bottom of the screen, it may be linked with that. It does not happen all the time when i bring the cursor at the bottom of the screen. It does not happen when all i have is background, but it does happen when i am over the gnome 2.2 panel, or if there is a few pixels of background between my xterm and the bottom of the screen. When in the gnome panel, it does not happen all the time, but only when on some icon or something which usually change color when i pass over it, and when part of the cursor is out of the screen in the bottom part. It does not happen when i move the gnome panel to the right or left of the screen and when part of the cursor is outside the screen. This is really strange to me, since the driver doesn't do any acceleration, and even the pixmap cache and OS memory management is not enabled, so i am rather lost, please someone help me out with this, or at least give me some indication as to what to do. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Hooking into mode setting: How to do it cleanly ?
On Wed, Mar 12, 2003 at 09:04:15AM +0100, Benjamin Herrenschmidt wrote: On Tue, 2003-03-11 at 21:49, Mark Vojkovich wrote: It's worth considering a helper function in the core server on Linux PPC that knows how to talk to the IVAD controller. These drivers could call it at the appropriate times. If it's just one function call in the driver and if they whole think is conditionally built, I don't think that sounds too bad. OK. Well, since I want also normal userland acess to it (so the user can change the brightness or screen geometry), I think the best is to move all of that stuff to a cmdline tool and have XFree call it with approriate parameter from that hook. That's also the best way to keep the XFree part of the code OS neutral (the external userland tool can then be ported on *BSD to whatever mecanism they provide for i2c communication on the CUDA and PMU busses). Why not make it a library, that could be used by a commandline/whatever frontend, or linked in with the XFree86 Server if needed. The portability remains, as you may just need to port the library. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple video consoles
On Fri, Mar 07, 2003 at 12:31:18PM +, Dr Andrew C Aitchison wrote:
On Fri, 7 Mar 2003, Sven Luther wrote:
I don't really agree here, modes are for the outgoing resolution, not
the input viewport. it would be far simpler to keep this simple
acceptation, and add a new keyword for defining the input viewport.
Have you looked at the Stretch option on say the NeoMagic driver ?
I have a 1024x768 laptop display, and by default (ie unless I use
option noStretch) all modes are stretched to fill the screen.
Thus the modes (and modelines) describe the viewport size, not the
output resolution.
Interesting, i suppose the scaling is also done in the driver then, i will
have a look at how it works when i get some free time.
I wonder how the driver knows what the laptop display size is ? do you
specify or does the monitor tell the driver about it with ddc ?
So I don't agree with your description of what the words currently mean.
Using viewport to describe the visible pixels of the
framebuffer and modes to describe the pixels of the monitor would be
logical and consistent, but it does mean a change from the way modes
is considered now.
Well, if you consider that the size given for the modes and the size of
the framebuffer are mostly exactly the same, you can hardly argue that
using modes for the framebuffer size is what most people think of when
they hear of modes.
Also, you have to consider how things work out from the driver
internals.
There is the DisplayModePtr mode, which as its name says is for the
outgoing mode, and has all the monitor timings. On the other hand, the
viewport source position and size is given by pScrn-frame{XY}{01},
which i suppose are calculated from the viewport (usually 0,0) and the
size of the current mode. Other framebuffer info include the
displaywidth (given by the virtual size, i guess) and the pixel depth.
So, we can do it in two ways :
1) As i said, we simply add the size to the viewport keywords, which
would be used to generate pScrn-frame{XY}{01}. No further driver
changes are needed, apart from setting the appropriate scaling factor,
or reject scaled modes if scalling is not allowed.
2) We do it the other way, we use the mode info to mean the viewport
source size. There is no way to set the real outgoing mode, so you can
only hope that the monitor provides you the real data (unless you add
a supported resolutions option to the monitor entry). And even such,
you have to calculate the new outgoing mode, and there is no practical
way for the user to specify the exact timing of the outgoing mode. No,
there is, i suppose you would be able to use a Supported line in the
monitor section and have there the lists of supported modes.
Both solution have advantages and disadvantages, i personnally think
that 1) is better, especially if you want to do more advanced stuff
later on, like zooming on windows (you would just call adjustframe each
time the window is moved) or such, it is also the one that needs least
overall changes.
Friendly,
Sven Luther
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Multiple video consoles
On Thu, Mar 06, 2003 at 12:27:41PM -0500, David Dawes wrote: On Tue, Mar 04, 2003 at 10:41:50AM +0100, Sven Luther wrote: I strongly advocate that you take in account such separation of the outgoing resolution and the framebuffer size in any future configuration scheme. We already have the Virtual size, which is the framebuffer size, and allows it to be separated from the viewport (mode) sizes. I don't think the outgoing resolution belongs in the Screen/Display sections. It should be between the Monitor data and the driver, with the driver using this information to determine the maximum viewport (mode) size allowable. Yes, but consider how the current display section works. You use the mode to specify outgoing resolution, but apart from the That's one way to look at it. Another way to look at it is that you use the mode to specify the viewport size and you don't really care about how that gets implemented. In the CRT case, both the viewport and outgoing resolution happen to be the same, so there is currently no distinction between these two. I think that the latter interpretation more closely matches what the user would expect when moving from a CRT display to an LCD display, and that's how things appear to be handled with most video BIOS and Windows drivers at present. But the mode contains more information than what is needed (the exact timings), which will not be used. And this may be confusing. It's imaginable that there might be displays that one day support multiple outgoing resolutions as well as using a scaler. It's also imaginable that displays will get smarter, and automatically take care of whatever resolution data the video card sends to it (as most CRT screens do today). I'd suspect the latter given how things have developed in the past. I don't know, i have the impression that this technology will more probably be part of the video card, and not the monitor, but that may be only me. I believe that the video card used in laptops also do the scaling if needed, from a comment i read on the linux-fbdev mailing list it seems that the fbdevs also do the scaling part themselves. But rather than speculating too much, it would be useful to do some research into current and developing standards/technology in this area. That would be usefull, yes. builtin mode, there is no guarantee that the string used for the modes even correspond to said resolution, the user are used to this, but if we are going to do scaling, it really don't make sense to use 800x600 as mode, when what you really want to say is that you want a resolution of 800x600. The parameters of the mode determine the resolution, not the name. Exactly, and the mode has much more info than what is needed for setting a viewport. However, a useful extension would be to place a special interpretation on mode names that fit a regular format (e.g., xresxyres@refresh). Yes, and these are what the monitors tell the card trough ddc anyway. For CRT output, the VESA GTF can be used to construct matching timings. For DVI output, the driver uses the resolution parameters to calculate the scaling. You see, again, you are speaking in video modes, but we want a framebuffer size. What does the refresh have in common with the framebuffer size ? It can evidently not be used to refer to the outgoing mode, which will have different timing parameters than what your xresxyres@refresh suggest. Also, if you still want to use a virtual screen bigger than the actual one, you still would need to specify the viewport. SubSection Display Virtual 1600 1200 Mode 1024x768 (outgoing mode). Resolution 1280 1024 Resolution 1024 768 Resolution 800 600 Resolution 640 480 EndSubSection This way, we would have a 1600x1200 virtual screen, an outgoing resolution of 1024x768, which could be specified in the monitor section, and resolutions of 640x480 upto 1280x1024. Sure, you could also use the modes, but you would give to much info, after all you would only need the size of the mode, and not the rest of it. For built-in modes, you only need to give the size now. With an extended interpretation for mode names as I suggested above, that would be the case for any mode size. For the outgoing monitor timings, yes i agree. I don't know, i still think that it would be best if we could separate the information as follows : 1) Information on the Framebuffer : virtual size and viewport size and position. If we have a shared framebuffer, then the virtual size is common to each head. Depth and Bpp information also goes here. 2) Information on the outgoing modes. This is taken from a list of builtin modes, or better yet from the data that the monitor sends back trough the DDC channel. And further, we would separate the information on the chips (the device section) and the screens, as in modern chips, a part of the configuration for both
Re: Multiple video consoles
On Mon, Mar 03, 2003 at 09:46:40PM -0500, David Dawes wrote: 2) a way to tell the framebuffer/viewport sizes for each supported resolution, something like : SubSection Display Mode 1024x768 Viewport 0 0 1024 768 Viewport 0 0 800 600 Viewport 0 0 640 480 EndSubSection or maybe SubSection Display Framebuffer 1024 768 Modes 1024x768 800x600 640x480 EndSubSection Erm, this is the other way around, the Modes give the Framebuffer size, and not the other way around, so, this one woudln't work. Which would tell the driver that we only support outgoing resolution of 1024x768, but that framebuffer resolution of 1024x768, 800x600, and 640x480 are ok, and that we should scale from them to the 1024x768 one. Maybe the syntax is not the best, but you get the idea. Actually, I don't understand what you're trying to do that can't be done already. The user shouldn't care that the panel is 1024x768 (other than that it's the max available mode resolution). The driver should figure that out and take care of scaling the user's 800x600 mode request to the physical output size of 1024x768. As a user, when I specify 800x600, I just want the physical screen to display an 800x600 pixel area on the full screen. I don't care of it's an 800x600 physical output mode or if the 800x600 is scaled to some other physical output resolution. Yes, but we need to change the way we calculate output mode, and use the fixed resolution, autodetected or with a monitor option like you propose below. The only new feature I see is that arbitrary scaling allows a potentially much finer set of mode sizes than we're currently used to, and this would be very useful for allowing real-time zooming and tracking windows (including resizes). That can be done with most modern CRTs too (with some horizontal granularity limits), but I imagine that zooming would be more seemless with the scaler method though than implementing it with CRT resolution changes. Yes. I could do this by using an outgoing resolution size in the device specific section, but this would not work best, since all the logic doing the mode setting now is done for the resolution in the display setting. Can the driver query the panel's size? If it can't, then it needs to be supplied somewhere. It could be a new Option in the Monitor section that the driver checks for. It would be best if the driver can auto-detect it though. I guess it can, DDC should be able to provide that, but i haven't got to there, and anyway, some monitor may have broken DDC, so better think of a Option for it, in the monitor section would be the best place for it. I strongly advocate that you take in account such separation of the outgoing resolution and the framebuffer size in any future configuration scheme. We already have the Virtual size, which is the framebuffer size, and allows it to be separated from the viewport (mode) sizes. I don't think the outgoing resolution belongs in the Screen/Display sections. It should be between the Monitor data and the driver, with the driver using this information to determine the maximum viewport (mode) size allowable. Yes, but consider how the current display section works. You use the mode to specify outgoing resolution, but apart from the builtin mode, there is no guarantee that the string used for the modes even correspond to said resolution, the user are used to this, but if we are going to do scaling, it really don't make sense to use 800x600 as mode, when what you really want to say is that you want a resolution of 800x600. Also, if you still want to use a virtual screen bigger than the actual one, you still would need to specify the viewport. SubSection Display Virtual 1600 1200 Mode 1024x768 (outgoing mode). Resolution 1280 1024 Resolution 1024 768 Resolution 800 600 Resolution 640 480 EndSubSection This way, we would have a 1600x1200 virtual screen, an outgoing resolution of 1024x768, which could be specified in the monitor section, and resolutions of 640x480 upto 1280x1024. Sure, you could also use the modes, but you would give to much info, after all you would only need the size of the mode, and not the rest of it. Some of the users of your driver probably will, so it's worth testing with it. Sure, but, err, its proprietary software i have no access too, right ? It never hurts to ask for a copy as a driver developer. The worst they can say is no. I find vmware very useful personally as well as for XFree86-related stuff (especially multi-platform build testing). Ok, Will be asking them. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple video consoles
On Sun, Mar 02, 2003 at 11:28:24PM -0500, David Dawes wrote: On Sat, Mar 01, 2003 at 10:34:20AM +0100, Sven Luther wrote: On Fri, Feb 28, 2003 at 04:19:37PM -0500, David Dawes wrote: Are you speaking about the current 4.3.0 or the stuff you are working on ? What I was working on. Ok, ... I take it, there will be a 4.4.0 before 5.0 ? Most likely. :)) 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. Mmm, you are speaking of a hardware scaller in the LCD monitor ? I'm talking about a scaler anywhere between where the resolution is programmed and the physical display. For laptop-type displays it's easy -- it's in the video hardware. For digital connections to LCD displays I'm not sure which side of the DVI connector it's normally located. I just know that I've seen it work in that case without needing to do anything special as a user or as a driver writer. I don't know whether the cases I've seen are common or unusual. I haven't played with enough of these HW combinations to know. Mmm, it may be something special in the bios of those laptops, or even some hardwired functionality, but in my case i need to program it by hand, and i guess other chips will need this too, so we may as well think of it. Well, from my experience (i have a Sony SDM-X52, with both a DVI connector and a standard VGA connector) this doesn't seem to happen. If i request a mode lower than what the LCD can display, i get only garbage, at least on the DVI channel. I believe the VGA channel can do more advanced things, but didn't sucessfully use them. On the other hand, my graphic hardware can do arbitrary scaling of the framebuffer before passing it to the monitor, but i have to program it explicitly. I guess that this is used by the bios at startup to convert the 640x480 text mode to something my monitor supports, since the fonts appear a bit blurry. It sounds like that in current cases the driver should handle this type of scaling transparently. The only extension that might be relevant is to allow the viewport to be set to a range of sizes rather than discrete mode sizes (as happens now). Well, i have to calculate the scaling factor from the source (framebuffer) width/height and the destination (mode resolution) width/height, that is why i ask for a more granular handling of this. Currently, you can do : Section Screen ... SubSection Display Depth 8 Modes 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 15 Modes 1024x768 800x600 640x480 EndSubSection ... EndSection (Well, actually, i have only 1024x768, since that is what the monitor supports.) What would be nice, would be if : 1) you could have only one line for all the depth/bpp, or a possibility to have multiple depth/bpp per display section. 2) a way to tell the framebuffer/viewport sizes for each supported resolution, something like : SubSection Display Mode 1024x768 Viewport 0 0 1024 768 Viewport 0 0 800 600 Viewport 0 0 640 480 EndSubSection or maybe SubSection Display Framebuffer 1024 768 Modes 1024x768 800x600 640x480 EndSubSection Which would tell the driver that we only support outgoing resolution of 1024x768, but that framebuffer resolution of 1024x768, 800x600, and 640x480 are ok, and that we should scale from them to the 1024x768 one. Maybe the syntax is not the best, but you get the idea. I could do this by using an outgoing resolution size in the device specific section, but this would not work best, since all the logic doing the mode setting now is done for the resolution in the display setting. I strongly advocate that you take in account such separation of the outgoing resolution and the framebuffer size in any future configuration scheme. Right. I've only seen downscaling, and it's possible that I'm wrong about it it happening in the monitor rather than in the video hardware. I think it is happening in the video hardware, at least for DVI connections. BTW, do you know any doc on DVI and LCD monitors ? my monitor refuse to go to sleep when i am using the DVI channel, while it works fine with the VGA channel. I haven't seen any docs on those. If there are related VESA specs, I should have them somewhere. Mmm, i will be also looking. That said, another thing that would be nice, would be the possibility to specify one display section for every depth, instead of just copying it for each supported depth. Do many people in these times of 64+Mo of onboard memory specify different resolutions for different depths ? I think it'd be useful to be able to specify paramters that apply to all depths, but still allow a depth-specific subsection to override. That'd be a useful extension
Re: Multiple video consoles
to be done separatedly. Right. 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. I haven't seen that happen, but if the VidMode extension is working correctly, it should be possible for an application to specify new video modes. They're supposed to be validated though, and the driver gets the opportunity to reject them. I haven't looked at SDL's internals in a long time, so I don't really know what it does now. Well, my driver is only half written, but the vesa driver also don't works correctly here. BTW, there are cases where vmware will do VBE calls of its own to provide good full-screen operation, and doesn't necessarily rely on modes provided in the config file. But that's a different story... I don't use wmware anyway, so ... Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple video consoles
On Fri, Feb 28, 2003 at 04:19:37PM -0500, David Dawes wrote: On Fri, Feb 28, 2003 at 09:04:06PM +0100, Sven Luther wrote: Are you speaking about the current 4.3.0 or the stuff you are working on ? What I was working on. BTW, is the stuff you were working on accessible on a CVS branch or something such ? Friendly, Sven Luther ___ 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: 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: 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: XRENDER extension docs?
On Wed, Feb 26, 2003 at 05:06:48PM -0800, Kendall Bennett wrote: Kurt Wall [EMAIL PROTECTED] wrote: Feigning erudition, Kendall Bennett wrote: % Hi Guys, % % Is thete any documentation on the XRENDER extension and more specifically % the Matrox implementation of it? Do any other drivers other than the % Matrox driver implement this extension? http://www.xfree86.org/~keithp/render/ $XFREE86ROOT/lib/X11/doc/render-protocol.txt Awesome, thanks! That gives a bit more information, but it doesn't really describe how the XAA drivers can accelerate the XRENDER extension. It Yes, it would indeed be great if the XAA.HOWTO would be expanded by a new paragraph speaking about the XRENDER acceleration hooks. There is already the xaa.h which gives some info, but a discution of the hooks would be welcome. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple video consoles
On Wed, Feb 26, 2003 at 09:40:18PM -0500, David Dawes wrote: On Wed, Feb 26, 2003 at 09:25:21PM +0100, Sven Luther wrote: On Wed, Feb 26, 2003 at 09:27:50PM +0200, Yitzhak Bar Geva wrote: Greatly encouraged by your response, thanks! Someone reported that X works with the multi-head console support in Linux 2.5 kernels. I did some searching for multi-head consoles under 2.5 kernel, but didn't see anything. I would be highly appreciative if you could give me some pointers. As far as I could see, the Linux Console Project is defunct, but there is definitely work on multiple input devices going on. The correct place is the linux-fbdev project on sourceforge, especially their mailing list, James Simmon is the main developper of the new console code, and you have to look into the late 2.5.5x at least to get working stuff. That said, XFree86 people don't like fbdev much, and anyway, i don't Not necessarily :-) I recently wrote an fbdev driver for Intel 830M and later chipsets (www.xfree86.org/~dawes/intelfb.html, and it should be in new -ac kernels). It was fun doing some graphics stuff outside of XFree86 for a change. It's basically a 2.4.x driver right now, and still needs to be ported to the latest 2.5.6x fbdev interfaces. Well, the 2.5.x drivers (the new API) are a lot easier to write, since a lot of common stuff has been abstracted. I have plans to write a HOWTO or something once i get time for it again. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple video consoles
On Wed, Feb 26, 2003 at 05:12:32PM -0600, jkjellman wrote: Absolutely right, but ... This can be done if two servers are used. The point I was making earlier in this thread was that used hacked kernels and servers are a bad thing. If two consoles (including keyboards) could be operated on a single box, then two separate X servers could also be run. The biggest problem is not the display, but rather that both X and Linux have a single console keyboard ingrained in their code. Any thoughts on how this might be circumvented using existing pieces? The new fbdev API and console layer should handle this just fine, not that i have personal experience with it, but that seemed to be the intention from what i followed in the linux-fbdev mailing list. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple video consoles
On Wed, Feb 26, 2003 at 10:47:39PM +, Andrew C Aitchison wrote: How do you imagine this would work when both head are using a shared accel (XAA or DRI) engine ? I thought that the whole point of the kernel DRI was to stop multiple apps from fighting over the hardware. If the X server and several libGL apps Well, it is more like multiple OpenGL X clients and the X drivers themselves. I don't hear of anyone running DRI on fbdev and X alongside each other, and all the stuff is initialized inside the X driver anyway. can share the hardware, adding another X server should be possible. It is not as simple, since for one chip driving two screens, there are some things that can only be done chip wide, and others that can be done separatedly on each head. Also, i think the DRI only bothers about the 3D engine, not really about things like mode setup and so. And even (onchip) memory management is not (yet) well separated. There is a proposal for DRI about that from Ian Romanick, but it does only concern the DRI, and it is not clear if the OS memory manager can be made to work with it also, or how. For it to work nicely the proposed extension to RandR which allows the frame-buffer to be re-arranged (remember that we have dropped on the fly trade off between depth and number of pixels from 4.3) would help, Mmm, there is another discution in the DRI mailing list about dual head with a single framebuffer, where i think RandR could be used to do one the fly head re-organization. But again, i don't really believe that this would help out if we plan to have two separate users, one on each head/seat/whatever. and I think we would want something (probably fbdev) to share out the frame-buffer. The fbdev and the drm would work, i think. You would use the fbdev for mode setting and such, and the drm for acceleration, the fbdev has not enough logic for it right now. but again, the fbdev and the drm don't cooperate very well, especially since the drm is initialized from the X driver. I suppose we could go the other way, and do two seats within one X server. Is this possible ? Not currently i guess, but it is a feature asked for since some time, for doing cheap terminals, instead of having one cheap box driving one terminal, you would driver two with it, thus almost halving the cost. That said, if one head crashes, the other goes too. I'd want one seat to be called say machine:0 and the other machine:1 ie listen on two sockets/ports. This would definitely be a case for two pointers and two sets of focus (which people seem to want for other reasons). Would the window scheduling be good enough to ensure that one seat can't consume all the cycles ? I'd be particularly worried that information could leak between seat. Do we use separate threads (or processes) for each seat; someone recently mentioned that the server isn't thread-safe. Conceptually I feel that all this should be left to the kernel, and we should run a separate X server for each seat. Lot of good questions ... 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. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Centralize XXXCopyMungedData
On Wed, Feb 26, 2003 at 04:30:44PM +0100, Egbert Eich wrote: Thomas Winischhofer writes: Egbert Eich wrote: Erm, I know that... :) What I actually meant was if Björn starts patching *drivers* (and that's what his statements sounded like) he'd better take care. OK, sorry, I misunderstood you. Patching individual drivers should be left to their maintainers or at least to somebody who has got HW to test. And a nice documentation of the new function would help a lot for that. BTW, is there any such documentation for the Render extension, and more precisely the XAA functions. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple video consoles
On Wed, Feb 26, 2003 at 06:40:07PM +, Dr Andrew C Aitchison wrote: On Wed, 26 Feb 2003, Yitzhak Bar Geva wrote: What is the status of simultaneous multiple video console operation for full multiuser X on one machine? Someone reported that X works with the multi-head console support in Linux 2.5 kernels. As far as I am concerned, that is the right way to go: get multi-heads working on the console, then run X on top of that. Does it really work ? With 2.4 multi-headed console, X blanks the second head when it launches, even if i don't display anything on the second head. I tried tailing the /var/log/XFree86.0.log on it, but to no avail. BTW, i suppose you mean dual head as in one X on one head, and another X (with another user, keyboard and mouse) on the second head. How do you imagine this would work when both head are using a shared accel (XAA or DRI) engine ? Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple video consoles
On Wed, Feb 26, 2003 at 09:27:50PM +0200, Yitzhak Bar Geva wrote: Greatly encouraged by your response, thanks! Someone reported that X works with the multi-head console support in Linux 2.5 kernels. I did some searching for multi-head consoles under 2.5 kernel, but didn't see anything. I would be highly appreciative if you could give me some pointers. As far as I could see, the Linux Console Project is defunct, but there is definitely work on multiple input devices going on. The correct place is the linux-fbdev project on sourceforge, especially their mailing list, James Simmon is the main developper of the new console code, and you have to look into the late 2.5.5x at least to get working stuff. That said, XFree86 people don't like fbdev much, and anyway, i don't think you can handle the dual head/one accel engine this way. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Start directions
On Fri, Jan 31, 2003 at 05:16:06AM -0800, r_linux wrote: Anybody have a document or draft of start of X ??? xdm | Xserver | ... I need to understand the Xfree86 source, and not sure where start... Look at the DESIGN document in xc/progras/Xserver/hw/xfree86/docs. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[Xpert]Re: [Dri-devel] Xv and OpenGL -- new module idea
On Mon, Sep 30, 2002 at 01:14:44PM -0700, Alex Deucher wrote: I'm pretty unfamiliar with OpenGL programming. I have an idea for an xfree module that I suspect would not be too hard to implement, but I wanted to get some other opinions on it. What I'd like to do is create a module called perhaps ogl-xv or glx-xv that would provide a generic Xv adapter on the front end and on the back end would implement it using openGL calls to basically create an RGB or YUV texture to render the video to. this would have the advantage of acceleration on cards with accelerated 3D, and would provide generic Xv support to cards lacking an overlay engine by using SW mesa, and it could provide for more than one Xv adapter, so you could theoretically have more than one Xv at a time. And it would allow (in the future) to do nice video tricks, like ATI is doing in their latest 9000 and 9700 based boards, using the pixel shaders to handle video. Do we have documentation available on these parts of those boards ? Friendly, Sven Luther ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
