Re: XAA2 namespace?
On Thu, Mar 04, 2004 at 02:43:53PM -0500, David Dawes wrote: > On Tue, Mar 02, 2004 at 12:06:53PM -0800, Mark Vojkovich wrote: > >On Tue, 2 Mar 2004, David Dawes wrote: > > > >> On Tue, Mar 02, 2004 at 10:57:04AM -0800, Mark Vojkovich wrote: > >> >On Tue, 2 Mar 2004, [ISO-8859-1] Frank Gießler wrote: > >> > > >> >> Mark Vojkovich wrote: > >> >> >We don't care what the filenames are except for the header files. > >> >> > The only reason why we care about header files is that a driver > >> >> > might include support for both and may need both include paths. > >> >> > There's only one exported header file. I'd like to name it Xaa.h > >> >> > to match the namespace. Is it really going to be relevant on > >> >> > case-unaware systems? Which ones are those BTW? > >> >> > >> >> There is already xaa.h. Having Xaa.h included at the same time is a > >> >> no-op for OS/2, for which there are already binaries for 4.4.0 available > >> >> (I would therefore consider this a well supported platform). > >> >> > >> > > >> > Well, then I guess I could call the header file xaa2.h > >> > >> Not to be too picky, but won't this be the third version of XAA, not the > >> second? > > > > Yes, it's actually the third. Harm's was the first. I think we > >even advertised XFree86 4.x's XAA as 2.0. Would you prefer xaa3.h ? > > I was just being picky. The main thing is that the file names and the > module name don't clash on case-insensitive systems. xaaa my sound like a nice prefix, in particular since you can shorten it to x3a, whose 3 would stand for the the third iteration of xaa ? Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
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 > >>Modes"1024x768" "800x600" "640x480" > >>EndSubSection > >>SubSection "Display" > >>Depth 24 > >>Modes"1024x768" "800x600" "640x480" > >>EndSubSection > >>EndSubSection > >>SubSection "Monitor1" > >>SubSection "Display" > >>Depth 16 > >>Modes"1024x768" "800x600" "640x480" > >>EndSubSection > >>SubSection "Display" > >>Depth 24 > >>Modes"1024x768" "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 Modes"1024x768" "800x600" "640x480" EndSubSection Or even : SubSection "Display" Modes"1024x768" "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 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: 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: 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 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: 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: [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
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 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: 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=R8&ht=1&satitle=video+card&sokeywordredirect=1&sosortproperty=1&sacategory=40156&catref=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: [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: [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: [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: [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: -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: -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: 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: Debian
On Thu, Jan 22, 2004 at 09:00:35PM -0700, Marc Aurele La France wrote: > On Thu, 22 Jan 2004, 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 > > plus patches (...-12.1) which is scheduled to be made their 'stable' release > > possibly in Feburary I believe. > > > Debian's Changelog for XFree86 4.2.1 > > <http://packages.debian.org/changelogs/pool/main/x/xfree86/xfree86_4.2.1-12.1/changelog> > > > 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. > > Yeah, and 4.3 is still "experimental" (not even "testing" or "unstable"), > and we're about to release 4.4... > > Anyway, what's this user's easiest path to 4.3? Install the experimental package (if he runs sarge or unstable already), if he runs woody, the best guess would be Michel Daenzer's dri-trunk packages : # Michel's DRI packages deb http://people.debian.org/~daenzer/dri-trunk ./ deb-src http://people.debian.org/~daenzer/dri-trunk ./ As backporting 4.3.0 to debian/woody needs that you already have a running 4.2.1 backport and some other dependency hell. Friendly, 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: 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: > > > > > > 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 Tue, Jan 13, 2004 at 05:35:50PM +0800, Yukun Chen wrote: > Yes. We have done some optimization for h/w acceleration RENDER > implementation but not including all aspects of our h/w. > > Also I think we can improve the 2D performance with the help of the > buddy in open source community. But no 3D drivers :(( Do you plane to make closed source 3D drivers available and if so, do you intent to provide also non x86 binaries (asking as developer for a company which does produce powerpc micro-atx motherboards). 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
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
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 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: "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: Kernel Module? On second thought...
On Tue, Oct 21, 2003 at 01:51:00PM -0400, Mike A. Harris wrote: > But for a 2D only driver, DRI based 2D acceleration using DMA is > more likely to be wasted effort than anything useful IMHO. > That's probably why nobody has done it yet other than in the > Radeon driver where it has a real good use. Well, it depends, modern cards might well not have other accel model than DMA, as does the i810 if i understood well, but as does the Wildcat VP from 3Dlabs too. Sure you could always not use the DMA engine and use onboard memory as ring buffers, but this is less than optimal, unless you have a system where neither agpgart nor pcigart works. But the DRI doesn't support these cases anyway. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: You suggest an upgrade, eh?
On Wed, Oct 15, 2003 at 09:50:12AM +0200, Måns Rullgård wrote: > Sven Luther <[EMAIL PROTECTED]> writes: > > >> >>>I've been trying to find specs for implementing hardware RENDER > >> >>>support for my graphics card. I have the specs for the card. The > >> >>>problem is that nobody seems to know what the various RENDER functions > >> >>>in a driver are supposed to do, or what the structs represent. > >> >>>Without this information, there's not much I can do. > >> >> > >> >>For a start, look at the mga or the sis driver. Both accelerate aa > >> >>texture blitting for aa text with quite remarkable speed improvements. > >> > > >> > > >> >I was hoping not to have to wade through hundreds of lines of chip > >> >specific code and try to guess what they tell the chip to do. If I > >> >only knew exactly what the functions are supposed to do, and what the > >> >supplied data is, it would be straight-forward to have my chip do the > >> >work. > >> > >> The parts that do RENDER accleration are by no means hundreds lines of > >> code. It plain two accelerator functions. I myself had no clue either > >> when I started, and implementing this took only one day. > > > > Then why has not someone added documentation for it in the XAA.HOWTO > > file, if it is that simple ? > > Good question. > > BTW, Sven. RENDER support for Permedia3 should be possible, right? Yep, there is no reason it should not. The only problem is that pm3 doesn't support per color alpha if i remember well, but i don't know if this is really needed for the part of RENDER accel that is discussed here. Still, it is inexcusable of the RENDER author to not provide documentation, after more than 2 years of asking for it, especially if it is that short. I hope to have again a working pm3 setup in two weeks or so, so i would be willing to test your code if you write it. In fact i already have an old pentium II motherboard, altough i don't have a case for it right now, nor RAM or a disk. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: You suggest an upgrade, eh?
On Tue, Oct 14, 2003 at 11:10:01PM +0200, Thomas Winischhofer wrote: > Måns Rullgård wrote: > >Thomas Winischhofer <[EMAIL PROTECTED]> writes: > > > >>>I've been trying to find specs for implementing hardware RENDER > >>>support for my graphics card. I have the specs for the card. The > >>>problem is that nobody seems to know what the various RENDER functions > >>>in a driver are supposed to do, or what the structs represent. > >>>Without this information, there's not much I can do. > >> > >>For a start, look at the mga or the sis driver. Both accelerate aa > >>texture blitting for aa text with quite remarkable speed improvements. > > > > > >I was hoping not to have to wade through hundreds of lines of chip > >specific code and try to guess what they tell the chip to do. If I > >only knew exactly what the functions are supposed to do, and what the > >supplied data is, it would be straight-forward to have my chip do the > >work. > > The parts that do RENDER accleration are by no means hundreds lines of > code. It plain two accelerator functions. I myself had no clue either > when I started, and implementing this took only one day. Then why has not someone added documentation for it in the XAA.HOWTO file, if it is that simple ? Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Starting XFree86 without an XF86Config file
On Thu, Oct 02, 2003 at 11:15:17AM -0700, Sottek, Matthew J wrote: > >The thing is, a unified device-configuring front-end would be better > >than having every driver writer roll their own. (I mean, we can follow > >Windows if we want, but why incur development risk by developing what > >essentially is several versions of the same thing?) > > Windows does it the way it does for a reason (the "Advanced" button on > the display prefs GUI) > > You will never be able to create a GUI that covers everything that is > configurable across a wide variety of vendor products... nor should > you try. Every vendor would like to have the ability to control unique > features of their driver in a unique way. It is fine to standardize > the basics, but if there is a "Custom output filer Foo" feature then > the vendor should be able to design a custom GUI to control it. > No matter how much you try to add to your standard GUI you will always > have vendors that would like to control one more, or they will not like > the controls for the features that exist. Notice that the DRI project has some configurable and extendable (or whatever) framework for specifying driver options, using XML to communicate between the driver and the user, trough a GUI or commandline or whatever. I don't know the status of this, but there where some discussion and early implementation of this in the past month. It is for configuring the 3D drivers though, so i don't know if it can be extended, or inspired from, for the standard XFree86 case. 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: 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: 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: radeon lockups with 4.3.0
On Fri, Aug 29, 2003 at 08:03:18PM -0400, Carl Nygard wrote: > On Fri, 2003-08-29 at 20:00, Michel Dänzer wrote: > > On Sat, 2003-08-30 at 00:46, Warren Turkal wrote: > > > I am using XFree86 4.3.0 on a Debian Sid system with kernel 2.6.0-test4. > > > Before I file a formal bug, I wanted to verify that it wasn't already fixed > > > in the CVS HEAD. > > > > > > I have a Radeon M7. The XServer locks up the machine every now and then. > > > When it locks up, the machine will still repsond to ACPI events (eg. acpid > > > will still shutdown the machine when I press the power putton). I am not > > > sure if the system is pingable at that point. The locking up is not changed > > > if I add option "NoAccel" "true" to the driver configuration clause in my > > > config file. > > > > In that case it can hardly be an X problem. Sounds rather like the > > kernel (anything interesting in its output? Does the same thing happen > > with 2.4 kernels?) or hardware. > > I just got a Compaq Presario x1000, with roughly the same setup (RH9, > 2.6.0-test4, Radeon Mobility 9200), and I've seen the exact same lockup > problems. Thing is, I've seen it even worse when I boot to XP, so I > wouldn't think it was necessarily related to X or even Linux (at least > in my case, don't know your hardware). > > One check, lots of times if X goes screwey, you can still telnet to your > machine from across the network, and kill X server manually, that should > get gdm/X to restart, if that indeed is the problem. Otherwise, you're > looking at kernel (or hardware) problems. BTW, i have a case where the glint driver freezes the server for a permedia2 chip. gdb debugging shows that it is busy waiting in the wait for free space routine of the accel engine, but killing the server and restarting it doesn't improve the situation, only a reset of the box will do. In this case, would a hardware problem also be the culprit ? The code in question has hardly changed since earlier versions of X, and it used to work well before. Overheating, dying power supply or graphic chip would be my first diagnostic here, altough i am waiting for the user to provide me output with more debugging info, in order to see which accel hook was called prior to the problem. 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: DPI with multiple heads and virtual desktops
On Sun, Aug 24, 2003 at 07:43:57PM -0400, David Dawes wrote: > On Sun, Aug 24, 2003 at 11:16:23PM +0200, Alexander Pohoyda wrote: > >David Dawes <[EMAIL PROTECTED]> writes: > > > >> >> >> Xinerama *hides* the fact that there are two heads, so there is no > >> >> >> way for the app to be told a different DPI debending which head it is > >> >> >> currently on - what should it be told if it is on both ? > >> >> > > >> >> >This is my point exactly. When I raised this issue it was not to elicit a > >> >> >"correct" solution, but rather to point out that the whole notion of DPI is > >> >> >nonsense WRT Xinerama/MergedFB. I would suggest this as a "correct-ish" > >> >> >solution: If Xinerama/MergedFB detects that both screens have nearly the > >> >> >same resolution (to within some configurable tolerance) then use the > >> >> >average of the two. Otherwise the user has to specify the DPI to use with > >> >> >the -dpi command line switch or some other mechanism. (Is there a DPI > >> >> >option in the XF86Config file?) It might be nice to be able to specify > >> >> >"use DPI from screen foo" in the ServerLayout section to simplify the > >> >> >process a bit. > >> >> > >> >> There is no DPI option in the XF86Config file, but one could be added. > >> > > >> >That's true, but we have DisplaySize property in the Monitor section. > >> > >> The -dpi command line option is global, applying to all screens. > > > >I see. Is it updated in the Xserver manual page? > >I have the old version which goes like this: > > -dpi resolution > > sets the resolution of the screen, in dots per > > inch. To be used when the server cannot determine > > the screen size from the hardware. > > I don't see how that description is inconsistent with what I said. > Maybe knowing how it works influences the way I read the description? Notice that framebuffer scalling, as we discussed last year, might be a good solution to this kind of problems, altough not all graphic card support it. The idea is to use, either a common framebuffer, or at least framebuffer with corresponding dpi and such information, and then scale them to the appropriate size when passing the data to the ramdac/whatever is used to draw the image on the screen. 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: 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 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 , cvs -r ) 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: 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+ 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: 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: Post-processing X-server output
On Thu, Aug 14, 2003 at 10:01:40AM +0200, Alexander Block wrote: > Hello, > > I want to post-process the output of an x-server. In detail I want to take > e.g. the desktop view of any windowmanager, apply some OpenGL image > manipulation functions to it and then send the manipulated image to the > graphic card. What is the best way to realize this behavior ? Does there > exist any documentation for further readings ? I would use a shadowfb using driver, and then do the postprocessing on the shadowfb chunks that are copied to the drivers. If i remember well, the copying function of the chunks of the shadow framebuffer are provided by the driver when initializing the shadowfb code. 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+ 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: 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+ 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: xfree86 for the VIA Apollo CLE266
On Sat, Aug 09, 2003 at 02:36:01PM -0400, David Dawes wrote: > >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. > > I think I can extract the date from the '$XFree86' line in the > CHANGELOG file and add it to the auto-generated xf86Build.h. While > I'm at it, I can adjust the auto-generation of xf86Build.h so that > its modification time doesn't change when its contents don't change. > > I've attached a patch for this. 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). > >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. > > It gets updated for most commits, but not necessarily every trivial one. But it gives an idea of the actual checkout. A range of dates at least. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Rant (was Re: ATI Drivers.)
On Sun, Jul 20, 2003 at 02:22:10AM -0400, Mike A. Harris wrote: > On Fri, 18 Jul 2003, Sven Luther wrote: > > >> driver models differ greatly. The kernel code would be custom > >> code written for the given operating systems involved, and almost > >> certainly written for high end high paying customers in the > >> scientific and other high end 3D customers in the marketplace. > > > >Maybe they could have the whole X driver and kernel module in open > >source, and only keep the opengl library as proprietary stuff. I more or > >less doubt they have any IP involved in these part, at least some really > >meaningfull stuff. This would it make much easier for user installations > >too, i think. > > Your guess is wrong. The kernel part contains the part that is > probably one of their most prized pieces of IP. I wont get into > details about that however as I don't know if discussing it would > violate my NDA with ATI or not. I do know however, that if there Well, i guess the other GPU manufacturer do it almost the same way, and also think it is higly secret stuff. > is one part of the drivers that would be the most unlikely to be > open sourced, it is the binary kernel blob. It does significant Which is the one place were the GPLed code place special restriction on using proprietary hardware, depending on who you ask naturally. > things that require extremely detailed in depth knowledge of the > chip way beyond anything anyone involved in OSS Radeon driver > development outside of ATI is likely to have docs or knowledge > on. I realize I can't "prove" this in any legal way for the > non-believers without possibly violating NDA, so believe what you > will. No, it is ok, i believe you. > I'd love to see it open sourced with complete details, but > realistically it isn't going to happen from _any_ vendor IMHO. Then they have to take the consequences, and provide proprietary drivers for all the architectures their hardware is probable to run on, which means that ati and nvidia should at least provide powerpc binaries, since powerpc is the most used arch after x86, and all of the apple ones are coming with nvidia or ati chips. The older ati based one where ok, since we had the r200 drivers, but not the nvidia ones, nor the newer radeon ones. I was going to buy a new powerbook, but there will probably never be open source 3D drivers for them, which means ATI or Nvidia have to provide them. Sure it cost them some, but this is the prize of doing closed source drivers. And if their drivers are of good quality, it should cost them no more than a rebuild on said arches, since both of them have mac OS X drivers anyway. > No vendor has provided that level of documentation to open source > vendors before. We get microcode to upload to the chips, and > that gives us something at least. Something better than nothing > IMHO, and I hope we continue to get this in the future too. I understand. > >> 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 > >drivers. > > Reverse engineering that level of code with no detailed knowledge > of the specific hardware underneath is an exercise in futility. > I challenge anyone to reverse engineer how any mainstream GPU > microcode engine works and produce any useful information on it > to be used by OSS developers to write a compiler to create new > microcode on the fly in the driver. If I see that within the Sure, it is futile for anyone, but the graphic chip industry has higly capable people with indepth knowledge of how graphic hardware does work. At least they should get as much information out of it than what you find in standard chip documentation. > next 20 years for even the oldest of Radeon hardware, I'll fall > off my chair in total shock. Not to mention that doing so is > probably even illegal in many countries, and would prevent any > knowledge gained from being used. Then there's the issue of Well, it is not illegal everywhere, and even the PC industry did that with the first IBM clones, so i guess even in the US it should be possible. That said, i don't think it is more legal to sell me hardware and then don't give me the necessary means to make use of it. It would be like selling cars without wheels. > anything reverse engineered possibly being patented also, making > it useless in OSS (in countries the patents are covered by). > > In short: Mindboggling amount of effort, for little to no gain, Compared to just run a powerpc build, and maybe for some other arch who also has agp support ? But then they have
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
Re: Rant (was Re: ATI Drivers.)
re you are exagerating. I hardly doubt that they would go broke or whatever if they released open source drivers. If anything, they would sell more boards. > > I really can't see the problem with these chip designers releasing > >information so there could be drivers written that can take advantage of > >ALL the features for the chips, and boards they produce! > > I'd love nothing 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
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: radeon 9200 (rv280) support
On Sat, Jun 07, 2003 at 07:07:32AM +0200, Alexander Stohr wrote: > (all expressed below is my personal opinion) > > there is a sound in the below text > which i dont like for misc reasons. > but ignoring my impressions, there might > be some basic clarifications needed. > > the xfree86 developers drove the policy to only > incoroporate highly "important fixes" for releases > that only differ in the last number of the version > number from the previous release. > "important fixes" were fixes for security holes and > could mean code changes for situations where crashes > might impact on system accessability and data integrity. > > having support for a new grafics board means adding > a new feature. but those feature changes are typically > only added to the development branch which will > possibly result in a package with middle number > incremented and minor number reset. > as of now that will be X4.4.0 or higher. Notice that i am working on fixing the SDK and making the trunk driver be able to build without problems with the latest major release (4.3.0 in this case). It should work for all the other drivers, but the ati driver broke compatibility in two minor areas which are easy to #ifdef out. I will try to look at this this weekend, and hope to get this fixed nextly, partly due to a patch from Matthew. If this does happen, then support for new graphic boards would become really easy to add even to major releases, and this whole point becomes much less important. Notice also that the future work of Eigbert Eich on the the future 4.4.0 SDK will make this much much easier, to the point of separate driver releases even maybe. What needs fixing in the ati driver is twofold : => The cards pci_ids information need to be moved inside each individual driver, so they come from the driver in the trunk driver, and not from the major release's SDK. => Some new fields and stuff which were not present in 4.3.0 need to be #ifdefed out. 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. Friendly, Sven Luther > if a feature change is so minor in its impact > and so small in size that it is no risk, then > it might sneak silently into a fix release. > extending for a new and somewhat different asic design > does not look to me like a thing of minor risk. > > i dont understand you complaining... > you seem to have a quite viable solution that even copes > with the existing binary packages, even then when they > are compiled by e.g. RedHat or whichever distribution. > its just a single line you have to add and you are done. > dont you like operating such things on your own risk. > (i hopefully assume now that the man page says > that the usage of this option is merely for experimental > purposes and that it's usages is totally on your own risk.) > > if you dont like adding such a line it all the time to your config > (how often does an end user delete his config file?) > then why not get the source and apply the patch to PCI ID listing > for the respective driver. compile the driver and install it. > done. > > hey, are you so keen on a release number? > you can even get development tree binaries > from misc sources. its a nice habit of the > XFree86 project to provide a few binaries > aside to the source, but you are on Linux > which is partuially a synonym for the GPL > FreeSoftware/OpenSource license, so please > expect that to be most software a gift from > the respective developer, but do not a expect > those developers to act like a business company. > > in order to get things in order, the XFree86 license > does grant you much more freedom than the GPL... > > > I would like to ask if it's possible to support the ATI > > radeon 9200 (rv280) in the next update of > > xfree86, maybe 4.3.1. I have found the following from > > Michael Hamilton ([EMAIL PROTECTED]) > > http://users.actrix.co.nz/michael/index.html on > > (comp.os.linux.x) below. > > Would it be possible to have built in support for this card > > using this info? > > Note: Most people DO NOT need agp 8x support
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: how to iterate through mode lists
On Fri, May 30, 2003 at 08:24:31AM -0700, Alex Deucher wrote: > If that's the case then's what's the best way to iterate through the > mode list without getting stuck in an endless loop? It's probably > somehting simple, but it's just not coming to me... For a circular list, you need to keep the original pointer around, and then travel the list until you get NULL (for the non circular list) or the original pointer, Something like : for (test=FALSE, p=modes; p!=NULL && (test && p != modes); test=TRUE, p = p->next); Fully untested, and may contain typos, but you get the idea. Friendly, Sven Luther ___ 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: IBM port replicator noise?
On Tue, May 27, 2003 at 12:52:39PM -0700, Alex Deucher wrote: > actually I believe the t30 has a full fledged mobility radeon 7500 on > board. regardless, the issue seems to be that the max res supported by > the DVI port is 1280x1024. running the port at 1200x1600 is beyond the > specs (and not supported). I don't really see this as a problem. if > you run at 1200x1600 you take your chances; if it works great, if not > then you are out of luck. Frankly most graphics cards I've seen max > out at 1280x1024 on the DVI port. The 3Dlabs Wildcat VP serie of boards are supposed to work with resolutions of upto 1920x1200 on the DVI port. I did not test this though as my flatscreen is only 1024x768. 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
Re: TFT displays
On Tue, Mar 25, 2003 at 02:24:25PM +0100, Davide Decicco wrote: > Hello, I am looking for some info about TFT LCD displays. In particular I am > interested in finding technical specs about them (detailed data sheets would > be great) since I am conducting a research and I need to know their inner > working (e.g. if they support internal DRAM, if they have image scalers on > board etc.). Can anyone help me ? Mmm, i don't really know, but i own a Sony SDM-X52, which has both a DVI entry and a VGA entry. The documentation mention that it does support 640x480, 800x600 and 1024x768, but i believe that this is only using the VGA entry, where the analog to digital converter does the scaling. I may be wrong though. The EDID gotten trough the DDC protocol shows these supported modes from either input, but when i try sending an 640x480 mode, i don't get it displayed. Also, my believe is that the scaling (for the digital entry) is done in the video chip, as seems the case for both the hardware i know and most common laptop graphic chips. The XFree86 neomagic chip at least seem to do so. Hope this helps a bit. 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 Mon, Mar 03, 2003 at 09:46:40PM -0500, David Dawes wrote: > >> >> 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 ... > >> > >> 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). Err, will the downloadable beta be ok for testing, or is it really needed to get a full solution ? 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
fer parameters separatedly. > >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 heads is common (like a shared framebuffer > >setting, but also other information, like the chip being able to use > >parts of one head for the other and other common configuration). This > >would also have an influence on the configuration file. > > > >> I think that a more important thing would be handling the specification > >> of a range of mode/viewport sizes so that smoother zooming could be > >> implemented. > > > >I am not sure i follow you here. > > How to you say that you want to allow all viewport sizes between 640x480 > and 1024x768 (i.e., any viewports XxY with X in [640,1024] and Y in > [480,768]). Maybe the answer is that you don't, and that the driver > determines what range the scaler can support. You are speaking viewport source size here or outgoing mode ? My first intention was that we don't, the user can specify an outgoing mode (or the monitor can tell what he supports), and a viewport input size. The driver then checks (in validatemode) if it can support this scaling, either choosing to reject it or to fall back to the next bigger supported input viewport and blank the margins or whatever. Then, there is no need to specify a range in the configuration file, the driver would handle that, more dynamic things could be done by expanding RandR to support scaling (and dynamic multi-head configurations). Now, if you want smooth zooming (going from one resolution to the another), then clearly, you don't haveto modify the outgoing mode, just the input viewport. And again, the driver is best placed to know about this, and anyway you would not handle this in the configuration file but in some dynamic change (or in RandR(andS)). But then, maybe i did not understand you well ? 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., x@). 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 x@ 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
Re: Multiple Video Consoles
On Wed, Mar 05, 2003 at 08:30:27AM -0800, Alex Deucher wrote: > Jonathan, > >could you also post your XF86Config file? I have some ideas on how > to extend this. It's still kind of a hack, but here goes: > > add an option to the radeon driver, say "MergedFB" or something like I was going to use option "Shared", but i guess "SharedFB" would be ok also. Shared seems more related to what we do than merged. > that. when that option is set to TRUE, it would skip the sections of > code that you have commented out. > > next add "sub" options for "MergedFB" like: > > Option "MFB-Xres" "2048" > Option "MFB-Yres" "768" > > these would set the virtualX and Y instead of having to hardcode them. Is anything wrong with using the Virtual field of the Display subsection ? It could be calculated by the driver, the only problem is that you need the both screens to already up to do that, this may be difficult. One thing i thought about was to check on which head we are when doing modeinit, and wait for the initialization of both heads before we can do the real modeinit, using information from both resolutions, but this seems somewhat hacky also. It is nicer than having to specify it in a driver option though. > it's still hackey, but would clean it up a bit and allow run time > configuration. BTW, what about the Xinerama hinting needed for desktop managers and such, will that work fine also ? Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
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
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
board memory specify different resolutions for different depths ? > >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. > > 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 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). >
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 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: 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 :0 and the other :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: 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 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: 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: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: 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: 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: driver developer docs for RENDER extension
On Mon, Feb 24, 2003 at 07:23:02AM +1100, Chris C wrote: > Hi, > > I am considering implementing the RENDER extension in a driver I am > working on, and was wondering if there were any docs along the lines > of the XAA.HOWTO that covers what the extension requires of me for > each function I implement ... I have looked at the source in mga_storm.c > and also at the info at eax.com and Keith's "developers guide to XRender", > but am not much the wiser. I was also searching for something such some time back, even asked on the list, but got no reply. > [While I'm sure I could work through it without such a thing, if there > were something out there, it sure would help ...] > BTW, if there's not, if someone could perhaps let me know what the > hardware needs to be able to do to make implementing the extension > worthwhile, it would at least allow me to make a decision as to > whether or not it's even possible for me to implement, prior to doing > any more research on it. The best information i got, was to look into xaa.h, in particular at the sections #ifdefed XRENDER, and like you did, at the mga_storm.c file. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
fixed size monitors and scaling ...
Hello, ... I am trying to enable the scaling functionality of the chipset i am currently writing a driver for. I wish it to be possible to specify a fixed size monitor (like an LCD screen) and then still allow the possibility of using other video modes and up (or down) scale them to the size of the fixed size monitor. Also it would be nice to have mirroring, where the second head mirrors the primary head, but maybe with another resolution, also using scaling here. Ok, now to my questions, how can i best specify this in the XF86Config file ? I simply used a fixedwidth/fixedheight option in the driver section, but this does not work best, since i need to have the timings for the fixed size, but the pres-scale size for the framebuffer. Also i believe this would be best specified in the monitor section and not in the driver section of the XF86Config file. Is there already a way of doing this, or maybe does a driver already do this (i think the closed source matrox ones does it, and mirroring, and windows zooming, but maybe not trough the XF86Config file). If not, it would be a nice feature for future XF5. BTW, how is it possible that SDL does switch to a mode not supported by my monitor, even if it is not in my XF86Config file ? This happen on my still incomplete driver, put also with the vesa driver. 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
Re: VT switching
On Thu, Jan 16, 2003 at 08:03:20AM +0800, Tan Wei Chong wrote: > Dear all, > > What exactly happen during a VT switching with say Ctrl-Alt-F2 ? > I mean how does the Xserver yield all its control over the display device such as >its access to frame buffer or overlay to console ? > Let say I have an application that continue to pump in video frame to the overlay >after the VT switch what would happen ? > I ask this because I'm curious about what happen to my Xv code when the user do a VT >switch ? You should disable/stop/whatever what you are doing to the HW in the VTLeave code and re-enable it in VTEnter. Normally, the X driver save/restore the ful HW state during VTEnter/VTLeave. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
