From postmaster Wed Mar 19 09:41:49 2003 Received: from hemlock.xfree86.org (du14155.wb.ptd.net [204.186.14.155]) by public.xfree86.org (8.12.8/8.12.8) with ESMTP id h2JHfmVr065894 for ; Wed, 19 Mar 2003 09:41:48 -0800 (PST) (envelope-from dawes@hemlock.xfree86.org) Received: (from dawes@localhost) by hemlock.xfree86.org (8.12.8/8.12.8/Submit) id h2JHflA0046326 for forum@xfree86.org; Wed, 19 Mar 2003 12:41:47 -0500 (EST) (envelope-from dawes) Date: Wed, 19 Mar 2003 12:41:47 -0500 From: David Dawes To: forum@xfree86.org Message-ID: <20030319124147.A46314@xfree86.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Spam-Status: No, hits=-4.6 required=6.0 tests=SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.41 X-Spam-Level: Subject: [Forum] test Sender: forum-admin@XFree86.Org Errors-To: forum-admin@XFree86.Org X-BeenThere: forum@XFree86.Org X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: forum@XFree86.Org List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Test From postmaster Wed Mar 19 21:10:32 2003 Received: from public.xfree86.org (localhost [127.0.0.1]) by public.xfree86.org (8.12.8/8.12.8) with ESMTP id h2K5AVVr086065; Wed, 19 Mar 2003 21:10:32 -0800 (PST) (envelope-from dawes@public.xfree86.org) Received: (from dawes@localhost) by public.xfree86.org (8.12.8/8.12.8/Submit) id h2K5AVTn086008; Thu, 20 Mar 2003 00:10:31 -0500 (EST) (envelope-from dawes) Date: Thu, 20 Mar 2003 00:10:31 -0500 From: XFree86 BOD To: forum@xfree86.org Message-ID: <20030320001031.B7189@xfree86.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Spam-Status: No, hits=-4.6 required=6.0 tests=SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.41 X-Spam-Level: Subject: [forum] Invitation for public discussion about the future of X Sender: forum-admin@XFree86.Org Errors-To: forum-admin@XFree86.Org X-BeenThere: forum@XFree86.Org X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: forum@XFree86.Org X-Reply-To: forum@XFree86.Org List-Help: List-Post: List-Subscribe: , List-Id: A public forum for discussion about the future of XFree86 List-Unsubscribe: , List-Archive: This is an invitation for anyone and everyone with an interest in X, XFree86, and related technologies and their future to participate in a public and open discussion. Any topics are open to discussion, from those related to administrative and management issues through to technical issues. A new mailing list has been created to provide an open forum for this discussion. To subscribe, go to . The list is unmoderated, and you don't need to subscribe to the list in order to post to it. An archive of the list is available at . This announcement has been blind-copied to all of the XFree86 public lists, but please send followups to the new forum@xfree86.org list. It has been brought to the attention of the XFree86 Core Team that one of its members, Keith Packard, has been actively (but privately) seeking out support for a fork of XFree86 that would be led by himself. He is also in the process of forming a by-invitation-only group of vested interests to discuss privately concerns he has about XFree86 and the future of X. He has consistently refused to even disclose these concerns within the context of the XFree86 Core Team, which makes his membership of that team unviable. As a consequence, Keith Packard is no longer a member of the XFree86 Core Team. The leaders of the XFree86 project feel that discussing the future of XFree86 and related technologies within a closed group of vested interests is contrary to the spirit of openness and community involvement that many of those vested interests claim to espouse. Instead, the involvement of everyone in a truly open discussion is welcomed by The XFree86 Project, and we invite everyone to express their thoughts, opinions and concerns freely in this open forum. We look forward to hearing and responding to them. The XFree86 Project BOD David Dawes Robin Cutshaw Marc Evans Rich Murphey Jon Tombs David Wexelblat From postmaster Wed Mar 19 21:57:37 2003 Received: from inpbox.inp.nsk.su (inpbox.inp.nsk.su [193.124.167.24]) by public.xfree86.org (8.12.8/8.12.8) with ESMTP id h2K5vYVr067699 for ; Wed, 19 Mar 2003 21:57:36 -0800 (PST) (envelope-from D.Yu.Bolkhovityanov@inp.nsk.su) Received: from Sky.inp.nsk.su (Sky.inp.nsk.su [193.124.167.84]) by inpbox.inp.nsk.su (8.12.1/8.12.1) with ESMTP id h2K5vMFD012337 for ; Thu, 20 Mar 2003 11:57:22 +0600 Received: from localhost (localhost [127.0.0.1]) by Sky.inp.nsk.su (8.9.1a/8.9.1) with ESMTP id LAA1051459 for ; Thu, 20 Mar 2003 11:57:26 +0600 (NSK) Date: Thu, 20 Mar 2003 11:57:25 +0600 From: "Dmitry Yu. Bolkhovityanov" To: forum@XFree86.Org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.2 required=6.0 tests=SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 X-Spam-Level: Subject: [forum] Mailing lists archives Sender: forum-admin@XFree86.Org Errors-To: forum-admin@XFree86.Org X-BeenThere: forum@XFree86.Org X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: forum@XFree86.Org List-Help: List-Post: List-Subscribe: , List-Id: A public forum for discussion about the future of XFree86 List-Unsubscribe: , List-Archive: Hi! Some time ago all *@xfree86.org maillists archives were available at www.xfree86.org/pipermail/ . Several months ago those had disappeared, which made much harm: while various sites on the Internet have these archives, the XFree86 site was THE archive, which could be linked to or searched through with Google. I personally always skimmed through Xpert list via archive, since the list volume was too big to receive it by e-mail. The cvs-commit list archive also was of great value. Now I simply don't read any lists besides Fonts, which had definitely decreased my acquaintance with XFree86 and my ability to do anything for the XFree86 project. I'm sure many people share my feelings. Now when there IS /pipermail/forum/, maybe it will be possible to restore other /pipermail/ archives? With best regards, Dmitry _________________________________________ Dmitry Yu. Bolkhovityanov The Budker Institute of Nuclear Physics Novosibirsk, Russia From postmaster Thu Mar 20 01:57:06 2003 Received: from hugin.diku.dk (qmailr@hugin.diku.dk [130.225.96.144]) by public.xfree86.org (8.12.8/8.12.8) with SMTP id h2K9v5Vr068206 for ; Thu, 20 Mar 2003 01:57:06 -0800 (PST) (envelope-from firefly@diku.dk) Received: (qmail 18256 invoked from network); 20 Mar 2003 09:57:03 -0000 Received: from tyr.diku.dk (firefly@130.225.96.226) by hugin.diku.dk with QMQP; 20 Mar 2003 09:57:03 -0000 Date: Thu, 20 Mar 2003 10:57:02 +0100 (MET) From: "Peter \"Firefly\" Lund" To: forum@xfree86.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.6 required=6.0 tests=SPAM_PHRASE_00_01 version=2.41 X-Spam-Level: Subject: [forum] I wish Keith Packard luck Sender: forum-admin@XFree86.Org Errors-To: forum-admin@XFree86.Org X-BeenThere: forum@XFree86.Org X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: forum@XFree86.Org List-Help: List-Post: List-Subscribe: , List-Id: A public forum for discussion about the future of XFree86 List-Unsubscribe: , List-Archive: I wish Keith Packard luck. I think he will be able to do a better job. I hope some of the vested interests include Linux distribution vendors like Red Hat, Connectiva, SuSE, etc. They have a good reason to see changes in the way XFree86 is run: http://www.advogato.org/person/mharris/diary.html?start=5 -Peter From postmaster Thu Mar 20 01:57:29 2003 Received: from fairlite.demon.co.uk (fairlite.demon.co.uk [158.152.52.252]) by public.xfree86.org (8.12.8/8.12.8) with ESMTP id h2K9vRVr068222 for ; Thu, 20 Mar 2003 01:57:28 -0800 (PST) (envelope-from alanh@fairlite.demon.co.uk) Received: from fairlite.demon.co.uk (localhost.localdomain [127.0.0.1]) by fairlite.demon.co.uk (8.12.5/8.12.5) with ESMTP id h2K9vQI0001327 for ; Thu, 20 Mar 2003 09:57:26 GMT Received: (from alanh@localhost) by fairlite.demon.co.uk (8.12.5/8.12.5/Submit) id h2K9vPCZ001325 for forum@xfree86.org; Thu, 20 Mar 2003 09:57:25 GMT Date: Thu, 20 Mar 2003 09:57:25 +0000 From: Alan Hourihane To: forum@xfree86.org Message-ID: <20030320095725.GA867@fairlite.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-4.6 required=6.0 tests=SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.41 X-Spam-Level: Subject: [forum] XFree86 5.0 TODO Sender: forum-admin@XFree86.Org Errors-To: forum-admin@XFree86.Org X-BeenThere: forum@XFree86.Org X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: forum@XFree86.Org List-Help: List-Post: List-Subscribe: , List-Id: A public forum for discussion about the future of XFree86 List-Unsubscribe: , List-Archive: Well, As this forum is for discussing all X stuff, here goes with a few notes from an XFree86 Core Team meeting from a little while back. So in the spirit of openness I thought I should discuss it here. This is stuff that we can think of that needs doing for XFree86 5.0, but by no means is it limited to this list or even guarantee'ing anything on the list will make it for 5.0. So, to spark discussions, here it is.... 1. Redesign of XAA, so that multiple depth pixmaps can be stored in offscreen memory and the creation of a new directive - called the XAASurface. There will undoubtably be driver work involved to port to the new interface. The techinical lead on this is Mark Vojkovich. I believe Mark has a substantial portion of this done, if not all. 2. FBManager extensions. This still needs furthur thought to encompass the requirements of all bases, but, the DRI is one that needs much more flexible memory management of the framebuffer. Secondly, it's been requested before for linear allocation, rather than the current area allocation code for some Xv implementations. 3. Xlib locale removal. By removing all the Xlc code from libX11 and see if we can layer it on top of iconv. Need to discuss the advantages and disadvantages of such a task. 4. DGA - do we leave in, or do we shelve it ? 5. RandR. We now have rotation support, but not depth switching yet. This still needs to be done. 6. PseudoColor emulation. Egbert Eich has written some preliminary code for this, and we're hoping he'll be able to release it soon. 7. Hot Plugging of devices. Displays, Keyboards, Mice. This is obviously tricky when running multiple Xservers on the same machine. How do you correlate which device is plugged in, to which Xserver etc. 8. Multiseat capability. Allowing multiple Xservers to run with independent graphics cards, keyboards and mice on the same machine. 9. Xc/Xr - A postscript rendering library for the RENDER extension replacing Xlib drawing routines. 10. Window translucency. 11. XFixes extension. 12. Gamma corrected RENDER 13. Potential DIX/DDX changes. Any other topics, please bring up for discussion. Alan. From postmaster Thu Mar 20 03:37:36 2003 Received: from hicks.adgrafix.com (hicks.adgrafix.com [64.55.193.2]) by public.xfree86.org (8.12.8/8.12.8) with ESMTP id h2KBbZVr046060 for ; Thu, 20 Mar 2003 03:37:36 -0800 (PST) (envelope-from keith_whitwell@yahoo.com) Received: from yahoo.com ([213.78.159.49]) by hicks.adgrafix.com (8.11.6+Sun/8.9.3) with ESMTP id h2KBbYP09475; Thu, 20 Mar 2003 06:37:34 -0500 (EST) Message-ID: <3E79A7FE.4070100@yahoo.com> Date: Thu, 20 Mar 2003 11:37:34 +0000 From: Keith Whitwell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: en-us, en MIME-Version: 1.0 To: forum@XFree86.Org, dri-devel References: <20030320001031.B7189@xfree86.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-5.2 required=6.0 tests=DISCLAIMER,EMAIL_ATTRIBUTION,FORGED_YAHOO_RCVD, QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 X-Spam-Level: Subject: [forum] Re: [XFree86] Invitation for public discussion about the future of X Sender: forum-admin@XFree86.Org Errors-To: forum-admin@XFree86.Org X-BeenThere: forum@XFree86.Org X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: forum@XFree86.Org List-Help: List-Post: List-Subscribe: , List-Id: A public forum for discussion about the future of XFree86 List-Unsubscribe: , List-Archive: XFree86 BOD wrote: > It has been brought to the attention of the XFree86 Core Team that one > of its members, Keith Packard, has been actively (but privately) seeking > out support for a fork of XFree86 that would be led by himself. He is > also in the process of forming a by-invitation-only group of vested > interests to discuss privately concerns he has about XFree86 and the > future of X. He has consistently refused to even disclose these concerns > within the context of the XFree86 Core Team, which makes his membership > of that team unviable. As a consequence, Keith Packard is no longer a > member of the XFree86 Core Team. What specifically does the XFree86 bod see as being wrong with the idea of a 'by-invitation-only group' managing X server development? Isn't that exactly what the core team & xfree86 BOD have been doing all along? Maybe the core team & bod could explain what is being hinted as a new spirit of openness and how that is proposed to effect the XFree86 development process and strategy? Will it mean forinstance an end to the sort of behind-closed-doors discussions that appear to have lead to this announcement? Please forgive my somewhat cynical tone... The best strategy to fight a fork would be to open up XFree & thereby make forking unnecessary. It seems like that is whats being attempted, but can the leopard change its spots? Sometimes I wonder if it knows it has them. OK - some concrete proposals, with cynicism turned off: - Make BOD minutes public - Open all core team meetings to the public, and if feasible post minutes, transcripts or even audio feeds. - Extend CVS access to regular contributors. Use scripts or whatever to control access to subtrees if you want. - Consider dropping the BOD and core team ideas in favour of an elected committee. Examine recent trends in managing other large projects. Just generally get down off your high horses and accept that the developers out there won't wreck xfree86 if you let them participate & accept them as equals... Of course, if xfree starts accepting more developers, it will make it harder for us in the dri tree as we tend to benefit from xfree's exclusionary practices -- developers find it easier to get cvs access for DRI than XFree86, so we pick up some talented developers that get fed up of waiting for patches to be applied to xfree cvs. But then again, what is the dri tree but a friendly fork to workaround for xfree's closed development methodology? If xfree really opened itself up, the first thing they'd do is extend an invitation to merge with the dri project, right? Maybe that's the acid test, or maybe it's whether we'd accept... Keith Disclaimer: Not speaking for anyone except myself, I had no prior knowledge of these events, and my employer is definitely *not* one of the 'vested interests' mentioned above. From postmaster Thu Mar 20 03:42:06 2003 Received: from mwinf0602.wanadoo.fr (smtp1.wanadoo.fr [193.252.22.25]) by public.xfree86.org (8.12.8/8.12.8) with ESMTP id h2KBg5Vr095390 for ; Thu, 20 Mar 2003 03:42:06 -0800 (PST) (envelope-from luther@dpt-info.u-strasbg.fr) Received: from iliana (AStrasbourg-206-1-27-62.abo.wanadoo.fr [81.51.32.62]) by mwinf0602.wanadoo.fr (Postfix) with ESMTP id 87C9A5400A8A for ; Thu, 20 Mar 2003 12:41:48 +0100 (CET) Received: from luther by iliana with local (Exim 3.36 #1 (Debian)) id 18vyQd-0000Nb-00 for ; Thu, 20 Mar 2003 12:41:47 +0100 Date: Thu, 20 Mar 2003 12:41:46 +0100 To: forum@xfree86.org Subject: Re: [forum] XFree86 5.0 TODO Message-ID: <20030320114146.GA1375@iliana> References: <20030320095725.GA867@fairlite.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030320095725.GA867@fairlite.demon.co.uk> User-Agent: Mutt/1.5.3i From: Sven Luther X-Spam-Status: No, hits=-13.4 required=6.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.41 X-Spam-Level: Sender: forum-admin@XFree86.Org Errors-To: forum-admin@XFree86.Org X-BeenThere: forum@XFree86.Org X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: forum@XFree86.Org List-Help: List-Post: List-Subscribe: , List-Id: A public forum for discussion about the future of XFree86 List-Unsubscribe: , List-Archive: On Thu, Mar 20, 2003 at 09:57:25AM +0000, Alan Hourihane wrote: > Well, > > As this forum is for discussing all X stuff, here goes with a few notes > from an XFree86 Core Team meeting from a little while back. So in the > spirit of openness I thought I should discuss it here. > > This is stuff that we can think of that needs doing for XFree86 5.0, but > by no means is it limited to this list or even guarantee'ing anything > on the list will make it for 5.0. > > So, to spark discussions, here it is.... > > 1. Redesign of XAA, so that multiple depth pixmaps can be stored in offscreen > memory and the creation of a new directive - called the XAASurface. There > will undoubtably be driver work involved to port to the new interface. The > techinical lead on this is Mark Vojkovich. I believe Mark has a substantial > portion of this done, if not all. Mmm, what would be the benefit of this one ? And how is the hardware side taken care of ? For example with graphic cards that don't have linear framebuffer, and where the pixmaps need to be converted (either in software or in hardware) before they are uploaded to the offscreen cache. Such non-linear memory organisation is sensitive to depth changes. > 2. FBManager extensions. This still needs furthur thought to encompass > the requirements of all bases, but, the DRI is one that needs much more > flexible memory management of the framebuffer. Secondly, it's been > requested before for linear allocation, rather than the current area > allocation code for some Xv implementations. Will this be X centric, or will we be able to share this framework with the fbdev or other graphic hardware accessing stuff ? If i understood it right, the DRI wanted to move most of this in the drm kernel module, no ? > 5. RandR. We now have rotation support, but not depth switching yet. This > still needs to be done. I personally am interested in dual/multi-head, and flexible configuration of viewports into a common framebuffer. I am not familiar with RandR, but i think it could be extended to allow dynamical head configuration or windows-zooming or other such functionality. > 7. Hot Plugging of devices. Displays, Keyboards, Mice. This is obviously > tricky when running multiple Xservers on the same machine. How do you > correlate which device is plugged in, to which Xserver etc. The display part at least is related to what i mention above. > 8. Multiseat capability. Allowing multiple Xservers to run with independent > graphics cards, keyboards and mice on the same machine. What about running multiple seats on the different heads of a same video chip ? You exclude that here, but with a common low level hw access and management layer (like the dma buffers of the DRI) i think it can be done. It may cause security concerns and such though. Anyway, for dual/multi-head on single graphic cards that support it, i would like to have us separate more the part related to the graphic chip from the part related to the output heads. Current multi-headed solutions (on the same chip) use a chip sharing trick, and the pEnt to store common information, but we could make this more formal, at least at the device driver level, and have things like preinit and part of the screeninit be done one time only for the entity, and then have multiple calls to modeinit for setting the viewports, the zooming, the outgoing resolution, the ddc info on the attached monitor and so on done per head. Friendly, Sven Luther From postmaster Thu Mar 20 04:21:15 2003 Received: from hicks.adgrafix.com (hicks.adgrafix.com [64.55.193.2]) by public.xfree86.org (8.12.8/8.12.8) with ESMTP id h2KCLDVr012677 for ; Thu, 20 Mar 2003 04:21:14 -0800 (PST) (envelope-from keith@tungstengraphics.com) Received: from tungstengraphics.com ([213.78.159.49]) by hicks.adgrafix.com (8.11.6+Sun/8.9.3) with ESMTP id h2KCLCP19616; Thu, 20 Mar 2003 07:21:12 -0500 (EST) Message-ID: <3E79B239.8030207@tungstengraphics.com> Date: Thu, 20 Mar 2003 12:21:13 +0000 From: Keith Whitwell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: en-us, en MIME-Version: 1.0 To: forum@XFree86.Org CC: dri-devel Subject: Re: [forum] Re: [XFree86] Invitation for public discussion about the future of X References: <20030320001031.B7189@xfree86.org> <3E79A7FE.4070100@yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-5.9 required=6.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 X-Spam-Level: Sender: forum-admin@XFree86.Org Errors-To: forum-admin@XFree86.Org X-BeenThere: forum@XFree86.Org X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: forum@XFree86.Org List-Help: List-Post: List-Subscribe: , List-Id: A public forum for discussion about the future of XFree86 List-Unsubscribe: , List-Archive: Keith Whitwell wrote: > XFree86 BOD wrote: > >> It has been brought to the attention of the XFree86 Core Team that one >> of its members, Keith Packard, has been actively (but privately) seeking >> out support for a fork of XFree86 that would be led by himself. He is >> also in the process of forming a by-invitation-only group of vested >> interests to discuss privately concerns he has about XFree86 and the >> future of X. He has consistently refused to even disclose these concerns >> within the context of the XFree86 Core Team, which makes his membership >> of that team unviable. As a consequence, Keith Packard is no longer a >> member of the XFree86 Core Team. > > > What specifically does the XFree86 bod see as being wrong with the idea > of a 'by-invitation-only group' managing X server development? Isn't > that exactly what the core team & xfree86 BOD have been doing all along? > > Maybe the core team & bod could explain what is being hinted as a new > spirit of openness and how that is proposed to effect the XFree86 > development process and strategy? Will it mean forinstance an end to > the sort of behind-closed-doors discussions that appear to have lead to > this announcement? It's always a shock to see that what is meant to tease when written comes out looking more like a direct attack when read back... Anyway, let me be explicit: I'm teasing, but there is a serious point buried in there. Keith From postmaster Thu Mar 20 04:36:35 2003 Received: from fairlite.demon.co.uk (fairlite.demon.co.uk [158.152.52.252]) by public.xfree86.org (8.12.8/8.12.8) with ESMTP id h2KCaWVr018870 for ; Thu, 20 Mar 2003 04:36:33 -0800 (PST) (envelope-from alanh@fairlite.demon.co.uk) Received: from fairlite.demon.co.uk (localhost.localdomain [127.0.0.1]) by fairlite.demon.co.uk (8.12.5/8.12.5) with ESMTP id h2KCaSI0001813 for ; Thu, 20 Mar 2003 12:36:29 GMT Received: (from alanh@localhost) by fairlite.demon.co.uk (8.12.5/8.12.5/Submit) id h2KCaSI1001811 for forum@XFree86.Org; Thu, 20 Mar 2003 12:36:28 GMT Date: Thu, 20 Mar 2003 12:36:28 +0000 From: Alan Hourihane To: forum@XFree86.Org Subject: Re: [forum] XFree86 5.0 TODO Message-ID: <20030320123628.GE867@fairlite.demon.co.uk> References: <20030320095725.GA867@fairlite.demon.co.uk> <20030320114146.GA1375@iliana> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030320114146.GA1375@iliana> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-13.4 required=6.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.41 X-Spam-Level: Sender: forum-admin@XFree86.Org Errors-To: forum-admin@XFree86.Org X-BeenThere: forum@XFree86.Org X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: forum@XFree86.Org List-Help: List-Post: List-Subscribe: , List-Id: A public forum for discussion about the future of XFree86 List-Unsubscribe: , List-Archive: On Thu, Mar 20, 2003 at 12:41:46 +0100, Sven Luther wrote: > On Thu, Mar 20, 2003 at 09:57:25AM +0000, Alan Hourihane wrote: > > Well, > > > > As this forum is for discussing all X stuff, here goes with a few notes > > from an XFree86 Core Team meeting from a little while back. So in the > > spirit of openness I thought I should discuss it here. > > > > This is stuff that we can think of that needs doing for XFree86 5.0, but > > by no means is it limited to this list or even guarantee'ing anything > > on the list will make it for 5.0. > > > > So, to spark discussions, here it is.... > > > > 1. Redesign of XAA, so that multiple depth pixmaps can be stored in offscreen > > memory and the creation of a new directive - called the XAASurface. There > > will undoubtably be driver work involved to port to the new interface. The > > techinical lead on this is Mark Vojkovich. I believe Mark has a substantial > > portion of this done, if not all. > > Mmm, what would be the benefit of this one ? And how is the hardware > side taken care of ? For example with graphic cards that don't have > linear framebuffer, and where the pixmaps need to be converted (either > in software or in hardware) before they are uploaded to the offscreen > cache. Such non-linear memory organisation is sensitive to depth > changes. I'll leave Mark to answer this one. > > 2. FBManager extensions. This still needs furthur thought to encompass > > the requirements of all bases, but, the DRI is one that needs much more > > flexible memory management of the framebuffer. Secondly, it's been > > requested before for linear allocation, rather than the current area > > allocation code for some Xv implementations. > > Will this be X centric, or will we be able to share this framework with > the fbdev or other graphic hardware accessing stuff ? If i understood it > right, the DRI wanted to move most of this in the drm kernel module, no ? We're in the X development forums, so I can see it being X centric. As for the DRI team wanting to move framebuffer allocation into the kernel - they have a document about it which probably should be repeated here. > > 5. RandR. We now have rotation support, but not depth switching yet. This > > still needs to be done. > > I personally am interested in dual/multi-head, and flexible > configuration of viewports into a common framebuffer. I am not familiar > with RandR, but i think it could be extended to allow dynamical head > configuration or windows-zooming or other such functionality. I think multihead in a common framebuffer is doable in the current infrastructure. > > 7. Hot Plugging of devices. Displays, Keyboards, Mice. This is obviously > > tricky when running multiple Xservers on the same machine. How do you > > correlate which device is plugged in, to which Xserver etc. > > The display part at least is related to what i mention above. > > > 8. Multiseat capability. Allowing multiple Xservers to run with independent > > graphics cards, keyboards and mice on the same machine. > > What about running multiple seats on the different heads of a same video > chip ? You exclude that here, but with a common low level hw access and > management layer (like the dma buffers of the DRI) i think it can be > done. It may cause security concerns and such though. I'm not excluding anything. This is just to open up discussions. The above seems to relate to a question you had furthur back in the message regarding multihead in a common framebuffer. As I've said, multihead in a common framebuffer should be doable in the current infrastructure, but multiseat in that environment suffers the same problems as with multiple graphics cards. The current issue, is the OS. As for Linux, we know the 2.5 kernel will be able to support concurrent VT's, so we'll need to take advantage of that. As for other OS'es, we'll need to figure out details. If there are others out there with knowledge on the other OS'es I'd welcome their thoughts here. > Anyway, for dual/multi-head on single graphic cards that support it, i > would like to have us separate more the part related to the graphic chip > from the part related to the output heads. Current multi-headed > solutions (on the same chip) use a chip sharing trick, and the pEnt to > store common information, but we could make this more formal, at least > at the device driver level, and have things like preinit and part of the > screeninit be done one time only for the entity, and then have multiple > calls to modeinit for setting the viewports, the zooming, the > outgoing resolution, the ddc info on the attached monitor and so on done > per head. multihead on a common framebuffer is obviously chip specific, so a lot of the details are specific to a driver. Again, for this, it should be doable now. Alan. From postmaster Thu Mar 20 04:48:12 2003 Received: from hicks.adgrafix.com (hicks.adgrafix.com [64.55.193.2]) by public.xfree86.org (8.12.8/8.12.8) with ESMTP id h2KCmCVr019179 for ; Thu, 20 Mar 2003 04:48:12 -0800 (PST) (envelope-from keith@tungstengraphics.com) Received: from tungstengraphics.com ([213.78.159.49]) by hicks.adgrafix.com (8.11.6+Sun/8.9.3) with ESMTP id h2KCmBP24642 for ; Thu, 20 Mar 2003 07:48:12 -0500 (EST) Message-ID: <3E79B88C.7090807@tungstengraphics.com> Date: Thu, 20 Mar 2003 12:48:12 +0000 From: Keith Whitwell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: en-us, en MIME-Version: 1.0 To: forum@XFree86.Org Subject: Re: [forum] XFree86 5.0 TODO References: <20030320095725.GA867@fairlite.demon.co.uk> <20030320114146.GA1375@iliana> <20030320123628.GE867@fairlite.demon.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-5.9 required=6.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 X-Spam-Level: Sender: forum-admin@XFree86.Org Errors-To: forum-admin@XFree86.Org X-BeenThere: forum@XFree86.Org X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: forum@XFree86.Org List-Help: List-Post: List-Subscribe: , List-Id: A public forum for discussion about the future of XFree86 List-Unsubscribe: , List-Archive: > >>Anyway, for dual/multi-head on single graphic cards that support it, i >>would like to have us separate more the part related to the graphic chip >>from the part related to the output heads. Current multi-headed >>solutions (on the same chip) use a chip sharing trick, and the pEnt to >>store common information, but we could make this more formal, at least >>at the device driver level, and have things like preinit and part of the >>screeninit be done one time only for the entity, and then have multiple >>calls to modeinit for setting the viewports, the zooming, the >>outgoing resolution, the ddc info on the attached monitor and so on done >>per head. > > > multihead on a common framebuffer is obviously chip specific, so a lot > of the details are specific to a driver. Again, for this, it should be > doable now. Alan - do you mean that there is some shared infrastructure there now for this, or that individual drivers can each extend what exists to get this going? There was once talk about a multithreaded X server - is this envisaged for XF5? What is the future of the work & extensions keithp was particularly involved with? Keith From postmaster Thu Mar 20 04:54:20 2003 Received: from mwinf0502.wanadoo.fr (smtp2.wanadoo.fr [193.252.22.26]) by public.xfree86.org (8.12.8/8.12.8) with ESMTP id h2KCsJVr019380 for ; Thu, 20 Mar 2003 04:54:20 -0800 (PST) (envelope-from luther@dpt-info.u-strasbg.fr) Received: from iliana (AStrasbourg-206-1-27-62.abo.wanadoo.fr [81.51.32.62]) by mwinf0502.wanadoo.fr (Postfix) with ESMTP id C847AE8021EF for ; Thu, 20 Mar 2003 13:53:53 +0100 (CET) Received: from luther by iliana with local (Exim 3.36 #1 (Debian)) id 18vzYO-0000fk-00 for ; Thu, 20 Mar 2003 13:53:52 +0100 Date: Thu, 20 Mar 2003 13:53:51 +0100 To: forum@xfree86.org Subject: Re: [forum] XFree86 5.0 TODO Message-ID: <20030320125351.GA2534@iliana> References: <20030320095725.GA867@fairlite.demon.co.uk> <20030320114146.GA1375@iliana> <20030320123628.GE867@fairlite.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030320123628.GE867@fairlite.demon.co.uk> User-Agent: Mutt/1.5.3i From: Sven Luther X-Spam-Status: No, hits=-13.4 required=6.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.41 X-Spam-Level: Sender: forum-admin@XFree86.Org Errors-To: forum-admin@XFree86.Org X-BeenThere: forum@XFree86.Org X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: forum@XFree86.Org List-Help: List-Post: List-Subscribe: , List-Id: A public forum for discussion about the future of XFree86 List-Unsubscribe: , List-Archive: On Thu, Mar 20, 2003 at 12:36:28PM +0000, Alan Hourihane wrote: > > > 2. FBManager extensions. This still needs furthur thought to encompass > > > the requirements of all bases, but, the DRI is one that needs much more > > > flexible memory management of the framebuffer. Secondly, it's been > > > requested before for linear allocation, rather than the current area > > > allocation code for some Xv implementations. > > > > Will this be X centric, or will we be able to share this framework with > > the fbdev or other graphic hardware accessing stuff ? If i understood it > > right, the DRI wanted to move most of this in the drm kernel module, no ? > > We're in the X development forums, so I can see it being X centric. Well, the discution yes, but the solution may be more generic, no ? > As for the DRI team wanting to move framebuffer allocation into the kernel - > they have a document about it which probably should be repeated here. Yes, ... > > > 5. RandR. We now have rotation support, but not depth switching yet. This > > > still needs to be done. > > > > I personally am interested in dual/multi-head, and flexible > > configuration of viewports into a common framebuffer. I am not familiar > > with RandR, but i think it could be extended to allow dynamical head > > configuration or windows-zooming or other such functionality. > > I think multihead in a common framebuffer is doable in the current > infrastructure. You are saying that it should be possible to use RandR to switch the viewport of both heads dynamically, like we change resolutions today ? > > > 7. Hot Plugging of devices. Displays, Keyboards, Mice. This is obviously > > > tricky when running multiple Xservers on the same machine. How do you > > > correlate which device is plugged in, to which Xserver etc. > > > > The display part at least is related to what i mention above. > > > > > 8. Multiseat capability. Allowing multiple Xservers to run with independent > > > graphics cards, keyboards and mice on the same machine. > > > > What about running multiple seats on the different heads of a same video > > chip ? You exclude that here, but with a common low level hw access and > > management layer (like the dma buffers of the DRI) i think it can be > > done. It may cause security concerns and such though. > > I'm not excluding anything. This is just to open up discussions. The above > seems to relate to a question you had furthur back in the message regarding > multihead in a common framebuffer. As I've said, multihead in a common > framebuffer should be doable in the current infrastructure, but multiseat > in that environment suffers the same problems as with multiple graphics > cards. The current issue, is the OS. As for Linux, we know the 2.5 kernel > will be able to support concurrent VT's, so we'll need to take advantage > of that. As for other OS'es, we'll need to figure out details. If there > are others out there with knowledge on the other OS'es I'd welcome their > thoughts here. Ok, ... BTW, when the X server dies for whatever reason, it would take both seats with him, right ? > > Anyway, for dual/multi-head on single graphic cards that support it, i > > would like to have us separate more the part related to the graphic chip > > from the part related to the output heads. Current multi-headed > > solutions (on the same chip) use a chip sharing trick, and the pEnt to > > store common information, but we could make this more formal, at least > > at the device driver level, and have things like preinit and part of the > > screeninit be done one time only for the entity, and then have multiple > > calls to modeinit for setting the viewports, the zooming, the > > outgoing resolution, the ddc info on the attached monitor and so on done > > per head. > > multihead on a common framebuffer is obviously chip specific, so a lot > of the details are specific to a driver. Again, for this, it should be > doable now. Yes, but not easily. The way i would do it currently is to set a virtual size that is the sum of both heads and inform the driver that the framebuffer is shared somehow. This would need the user to setup things. Another way of doing this is, in the driver, to wait that the information about both heads mode are given to the driver, and then sum them up and do a the framebuffer allocation then. This could be done in preinit, i think, but again, you would need to get access to the other head's framebuffer layout information and modify it, which is not the cleanest thing to do. If we are going to rework things, we could as well clean this up, no ? Friendly, Sven Luther From postmaster Thu Mar 20 05:07:00 2003 Received: from fairlite.demon.co.uk (fairlite.demon.co.uk [158.152.52.252]) by public.xfree86.org (8.12.8/8.12.8) with ESMTP id h2KD6wVr019810 for ; Thu, 20 Mar 2003 05:06:59 -0800 (PST) (envelope-from alanh@fairlite.demon.co.uk) Received: from fairlite.demon.co.uk (localhost.localdomain [127.0.0.1]) by fairlite.demon.co.uk (8.12.5/8.12.5) with ESMTP id h2KD6vI0001846 for ; Thu, 20 Mar 2003 13:06:58 GMT Received: (from alanh@localhost) by fairlite.demon.co.uk (8.12.5/8.12.5/Submit) id h2KD6vfr001844 for forum@XFree86.Org; Thu, 20 Mar 2003 13:06:57 GMT Date: Thu, 20 Mar 2003 13:06:57 +0000 From: Alan Hourihane To: forum@XFree86.Org Subject: Re: [forum] XFree86 5.0 TODO Message-ID: <20030320130657.GF867@fairlite.demon.co.uk> References: <20030320095725.GA867@fairlite.demon.co.uk> <20030320114146.GA1375@iliana> <20030320123628.GE867@fairlite.demon.co.uk> <3E79B88C.7090807@tungstengraphics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E79B88C.7090807@tungstengraphics.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-14.1 required=6.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT,USER_AGENT_MUTT version=2.41 X-Spam-Level: Sender: forum-admin@XFree86.Org Errors-To: forum-admin@XFree86.Org X-BeenThere: forum@XFree86.Org X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: forum@XFree86.Org List-Help: List-Post: List-Subscribe: , List-Id: A public forum for discussion about the future of XFree86 List-Unsubscribe: , List-Archive: On Thu, Mar 20, 2003 at 12:48:12 +0000, Keith Whitwell wrote: > > > >>Anyway, for dual/multi-head on single graphic cards that support it, i > >>would like to have us separate more the part related to the graphic chip > >>from the part related to the output heads. Current multi-headed > >>solutions (on the same chip) use a chip sharing trick, and the pEnt to > >>store common information, but we could make this more formal, at least > >>at the device driver level, and have things like preinit and part of the > >>screeninit be done one time only for the entity, and then have multiple > >>calls to modeinit for setting the viewports, the zooming, the > >>outgoing resolution, the ddc info on the attached monitor and so on done > >>per head. > > > > > >multihead on a common framebuffer is obviously chip specific, so a lot > >of the details are specific to a driver. Again, for this, it should be > >doable now. > > Alan - do you mean that there is some shared infrastructure there now for > this, or that individual drivers can each extend what exists to get this > going? Both. The mga driver is a good example of using a second crt. But also XAA has specific changes to share a graphics accelerator. There is also some helper code in xfree86/common that can detect when your using a shared entity. Additionally the overlay code xf8_16bpp actually sets up an 8bpp and a 16bpp framebuffer, and if the chip supports it, it does the overlay so you can use both simultaneously. I believe the chips driver does support this mode of operation. > There was once talk about a multithreaded X server - is this envisaged for > XF5? There's not been talk of a multithreaded Xserver for 5.0, or for quite some time. Although there was some work quite some time ago to investigate this.... That was called MTXserver and the code is still available from the XFree86 CVS, but MTXserver is extremely old. It's under xc/workInProgress/MTXserver if you want to take a closer look. > What is the future of the work & extensions keithp was particularly > involved with? Your guess is as good as mine. Alan. From postmaster Thu Mar 20 05:19:25 2003 Received: from ejc.ecomda.com (ejc.ecomda.com [212.18.24.150]) by public.xfree86.org (8.12.8/8.12.8) with ESMTP id h2KDJOVr058618 for ; Thu, 20 Mar 2003 05:19:25 -0800 (PST) (envelope-from torgeir@pobox.com) Received: (qmail 2832 invoked from network); 20 Mar 2003 13:20:36 -0000 Received: from unknown (HELO [192.168.0.248]) (torgeir@[212.36.39.235]) (envelope-sender ) by 0 (qmail-ldap-1.03) with SMTP for ; 20 Mar 2003 13:20:36 -0000 From: Torgeir Veimo To: forum@XFree86.Org Content-Type: text/plain Organization: Message-Id: <1048166362.3846.28.camel@atlantis.marketpipe.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-3) Date: 20 Mar 2003 13:19:22 +0000 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.0 required=6.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.41 X-Spam-Level: Subject: [forum] Keith Packard issue Sender: forum-admin@XFree86.Org Errors-To: forum-admin@XFree86.Org X-BeenThere: forum@XFree86.Org X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: forum@XFree86.Org List-Help: List-Post: List-Subscribe: , List-Id: A public forum for discussion about the future of XFree86 List-Unsubscribe: , List-Archive: FYI: the Keith Packard issue is now on Slashdot.org. -- Torgeir Veimo From postmaster Thu Mar 20 05:12:43 2003 Received: from fairlite.demon.co.uk (fairlite.demon.co.uk [158.152.52.252]) by public.xfree86.org (8.12.8/8.12.8) with ESMTP id h2KDCgVr038958 for ; Thu, 20 Mar 2003 05:12:42 -0800 (PST) (envelope-from alanh@fairlite.demon.co.uk) Received: from fairlite.demon.co.uk (localhost.localdomain [127.0.0.1]) by fairlite.demon.co.uk (8.12.5/8.12.5) with ESMTP id h2KDCfI0001854 for ; Thu, 20 Mar 2003 13:12:41 GMT Received: (from alanh@localhost) by fairlite.demon.co.uk (8.12.5/8.12.5/Submit) id h2KDCfHX001852 for forum@XFree86.Org; Thu, 20 Mar 2003 13:12:41 GMT Date: Thu, 20 Mar 2003 13:12:41 +0000 From: Alan Hourihane To: forum@XFree86.Org Subject: Re: [forum] XFree86 5.0 TODO Message-ID: <20030320131241.GG867@fairlite.demon.co.uk> References: <20030320095725.GA867@fairlite.demon.co.uk> <20030320114146.GA1375@iliana> <20030320123628.GE867@fairlite.demon.co.uk> <20030320125351.GA2534@iliana> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030320125351.GA2534@iliana> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-13.4 required=6.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.41 X-Spam-Level: Sender: forum-admin@XFree86.Org Errors-To: forum-admin@XFree86.Org X-BeenThere: forum@XFree86.Org X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: forum@XFree86.Org List-Help: List-Post: List-Subscribe: , List-Id: A public forum for discussion about the future of XFree86 List-Unsubscribe: , List-Archive: On Thu, Mar 20, 2003 at 01:53:51 +0100, Sven Luther wrote: > On Thu, Mar 20, 2003 at 12:36:28PM +0000, Alan Hourihane wrote: > > > > 2. FBManager extensions. This still needs furthur thought to encompass > > > > the requirements of all bases, but, the DRI is one that needs much more > > > > flexible memory management of the framebuffer. Secondly, it's been > > > > requested before for linear allocation, rather than the current area > > > > allocation code for some Xv implementations. > > > > > > Will this be X centric, or will we be able to share this framework with > > > the fbdev or other graphic hardware accessing stuff ? If i understood it > > > right, the DRI wanted to move most of this in the drm kernel module, no ? > > > > We're in the X development forums, so I can see it being X centric. > > Well, the discution yes, but the solution may be more generic, no ? Potentially. > > As for the DRI team wanting to move framebuffer allocation into the kernel - > > they have a document about it which probably should be repeated here. > > Yes, ... > > > > > 5. RandR. We now have rotation support, but not depth switching yet. This > > > > still needs to be done. > > > > > > I personally am interested in dual/multi-head, and flexible > > > configuration of viewports into a common framebuffer. I am not familiar > > > with RandR, but i think it could be extended to allow dynamical head > > > configuration or windows-zooming or other such functionality. > > > > I think multihead in a common framebuffer is doable in the current > > infrastructure. > > You are saying that it should be possible to use RandR to switch the > viewport of both heads dynamically, like we change resolutions today ? I'm not thinking RandR here. More a static approach by splitting the framebuffer up into two portions, one for use as though it's an independent card. Then XAA can share the graphics accelerator to write to both regions. I understand this is the way of the mga driver that does it now. There'd be a need for better framebuffer management to support depth switching for RandR in this environment, which comes back to point 2. > > > > 7. Hot Plugging of devices. Displays, Keyboards, Mice. This is obviously > > > > tricky when running multiple Xservers on the same machine. How do you > > > > correlate which device is plugged in, to which Xserver etc. > > > > > > The display part at least is related to what i mention above. > > > > > > > 8. Multiseat capability. Allowing multiple Xservers to run with independent > > > > graphics cards, keyboards and mice on the same machine. > > > > > > What about running multiple seats on the different heads of a same video > > > chip ? You exclude that here, but with a common low level hw access and > > > management layer (like the dma buffers of the DRI) i think it can be > > > done. It may cause security concerns and such though. > > > > I'm not excluding anything. This is just to open up discussions. The above > > seems to relate to a question you had furthur back in the message regarding > > multihead in a common framebuffer. As I've said, multihead in a common > > framebuffer should be doable in the current infrastructure, but multiseat > > in that environment suffers the same problems as with multiple graphics > > cards. The current issue, is the OS. As for Linux, we know the 2.5 kernel > > will be able to support concurrent VT's, so we'll need to take advantage > > of that. As for other OS'es, we'll need to figure out details. If there > > are others out there with knowledge on the other OS'es I'd welcome their > > thoughts here. > > Ok, ... > > BTW, when the X server dies for whatever reason, it would take both > seats with him, right ? Right. > > > Anyway, for dual/multi-head on single graphic cards that support it, i > > > would like to have us separate more the part related to the graphic chip > > > from the part related to the output heads. Current multi-headed > > > solutions (on the same chip) use a chip sharing trick, and the pEnt to > > > store common information, but we could make this more formal, at least > > > at the device driver level, and have things like preinit and part of the > > > screeninit be done one time only for the entity, and then have multiple > > > calls to modeinit for setting the viewports, the zooming, the > > > outgoing resolution, the ddc info on the attached monitor and so on done > > > per head. > > > > multihead on a common framebuffer is obviously chip specific, so a lot > > of the details are specific to a driver. Again, for this, it should be > > doable now. > > Yes, but not easily. The way i would do it currently is to set a virtual > size that is the sum of both heads and inform the driver that the > framebuffer is shared somehow. This would need the user to setup things. > Another way of doing this is, in the driver, to wait that the > information about both heads mode are given to the driver, and then sum > them up and do a the framebuffer allocation then. This could be done in > preinit, i think, but again, you would need to get access to the other > head's framebuffer layout information and modify it, which is not the > cleanest thing to do. If we are going to rework things, we could as well > clean this up, no ? Take a closer look at the mga driver. Alan. From postmaster Thu Mar 20 05:42:05 2003 Received: from ns2.tudelft.nl (ns2.tudelft.nl [130.161.180.65]) by public.xfree86.org (8.12.8/8.12.8) with ESMTP id h2KDg4Vr069576 for ; Thu, 20 Mar 2003 05:42:05 -0800 (PST) (envelope-from m.j.w.sipkema@student.tudelft.nl) Received: from CONVERSION-DAEMON.mailhost1.tudelft.nl by mailhost1.tudelft.nl (PMDF V6.1-1 #40924) id <0HC100901VE203@mailhost1.tudelft.nl> for forum@XFree86.Org; Thu, 20 Mar 2003 14:42:03 +0100 (MET) Received: from lr0nt3.lr.tudelft.nl (lr0nt3.lr.tudelft.nl [130.161.166.23]) by mailhost1.tudelft.nl (PMDF V6.1-1 #40924) with ESMTP id <0HC1003KSVE2S6@mailhost1.tudelft.nl> for forum@XFree86.Org; Thu, 20 Mar 2003 14:42:02 +0100 (MET) Received: from boromir (boromir.lr-s.tudelft.nl [145.94.77.58]) by lr0nt3.lr.tudelft.nl with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id FR8LALQ2; Thu, 20 Mar 2003 14:42:04 +0100 Date: Thu, 20 Mar 2003 14:41:53 +0100 From: Martijn Sipkema To: forum@XFree86.Org Message-id: <001801c2eee6$77f8fb90$161b14ac@boromir> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Status: No, hits=1.5 required=6.0 tests=INVALID_MSGID,SPAM_PHRASE_00_01,USER_AGENT_OE version=2.41 X-Spam-Level: * Subject: [forum] some XFree86 5.0 questions... Sender: forum-admin@XFree86.Org Errors-To: forum-admin@XFree86.Org X-BeenThere: forum@XFree86.Org X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: forum@XFree86.Org X-Reply-To: Martijn Sipkema List-Help: List-Post: List-Subscribe: , List-Id: A public forum for discussion about the future of XFree86 List-Unsubscribe: , List-Archive: LS. How does SGI's Xdc extension and the OpenML MLdc library (http://www.khronos.org) compare to RandR? Will XFree86 5.0 use Xft for font rendering or might it (also) use Sun's STSF (http://stsf.sf.net)? --ms From postmaster Thu Mar 20 06:01:25 2003 Received: from devserv.devel.redhat.com (nat-pool-rdu.redhat.com [66.187.233.200]) by public.xfree86.org (8.12.8/8.12.8) with ESMTP id h2KE1OVr070308 for ; Thu, 20 Mar 2003 06:01:25 -0800 (PST) (envelope-from alan@redhat.com) Received: (from alan@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id h2KE1OM04940 for forum@XFree86.Org; Thu, 20 Mar 2003 09:01:24 -0500 From: Alan Cox Message-Id: <200303201401.h2KE1OM04940@devserv.devel.redhat.com> Subject: Re: [forum] Keith Packard issue To: forum@XFree86.Org Date: Thu, 20 Mar 2003 09:01:24 -0500 (EST) In-Reply-To: <1048166362.3846.28.camel@atlantis.marketpipe.com> from "Torgeir Veimo" at Mar 20, 2003 01:19:22 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.0 required=6.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.41 X-Spam-Level: Sender: forum-admin@XFree86.Org Errors-To: forum-admin@XFree86.Org X-BeenThere: forum@XFree86.Org X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: forum@XFree86.Org List-Help: List-Post: List-Subscribe: , List-Id: A public forum for discussion about the future of XFree86 List-Unsubscribe: , List-Archive: > FYI: the Keith Packard issue is now on Slashdot.org. The "Keith Packard" issue or the XFree86 issue ? From postmaster Thu Mar 20 06:06:50 2003 Received: from ejc.ecomda.com (ejc.ecomda.com [212.18.24.150]) by public.xfree86.org (8.12.8/8.12.8) with ESMTP id h2KE6nVr070518 for ; Thu, 20 Mar 2003 06:06:50 -0800 (PST) (envelope-from torgeir@pobox.com) Received: (qmail 6091 invoked from network); 20 Mar 2003 14:08:01 -0000 Received: from unknown (HELO [192.168.0.248]) (torgeir@[212.36.39.235]) (envelope-sender ) by 0 (qmail-ldap-1.03) with SMTP for ; 20 Mar 2003 14:08:01 -0000 Subject: Re: [forum] Keith Packard issue From: Torgeir Veimo To: forum@XFree86.Org In-Reply-To: <200303201401.h2KE1OM04940@devserv.devel.redhat.com> References: <200303201401.h2KE1OM04940@devserv.devel.redhat.com> Content-Type: text/plain Organization: Message-Id: <1048169208.3846.33.camel@atlantis.marketpipe.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-3) Date: 20 Mar 2003 14:06:48 +0000 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-7.3 required=6.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01 version=2.41 X-Spam-Level: Sender: forum-admin@XFree86.Org Errors-To: forum-admin@XFree86.Org X-BeenThere: forum@XFree86.Org X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: forum@XFree86.Org List-Help: List-Post: List-Subscribe: , List-Id: A public forum for discussion about the future of XFree86 List-Unsubscribe: , List-Archive: On Thu, 2003-03-20 at 14:01, Alan Cox wrote: > > FYI: the Keith Packard issue is now on Slashdot.org. > > The "Keith Packard" issue or the XFree86 issue ? Good point. I guess both. I wish there was more openess about it all. -- Torgeir Veimo From postmaster Thu Mar 20 06:11:06 2003 Received: from magic.shiman.com (magic.shiman.com [199.103.167.18]) by public.xfree86.org (8.12.8/8.12.8) with ESMTP id h2KEB6Vr070702 for ; Thu, 20 Mar 2003 06:11:06 -0800 (PST) (envelope-from leon@magic.shiman.com) Received: from magic.shiman.com (magic.shiman.com [199.103.167.18]) by magic.shiman.com (8.11.6/8.11.6) with SMTP id h2KEB5916946 for ; Thu, 20 Mar 2003 09:11:05 -0500 (EST) Message-Id: <200303201411.h2KEB5916946@magic.shiman.com> Date: Thu, 20 Mar 2003 09:11:05 -0500 (EST) From: Leon Shiman To: forum@XFree86.Org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: nzEMem3T/R4+EavvBd3QGA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 i86pc i386 X-Spam-Status: No, hits=1.7 required=6.0 tests=OPPORTUNITY_2,SPAM_PHRASE_02_03 version=2.41 X-Spam-Level: * Subject: [forum] thank you david dawes! Sender: forum-admin@XFree86.Org Errors-To: forum-admin@XFree86.Org X-BeenThere: forum@XFree86.Org X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: forum@XFree86.Org X-Reply-To: Leon Shiman List-Help: List-Post: List-Subscribe: , List-Id: A public forum for discussion about the future of XFree86 List-Unsubscribe: , List-Archive: I would like to see this forum yield an open, fully internationalized group in which the common interests, goals, and responsiblities of Xfree86 and X.Org can be joined. Such a strengthened X Community, as providers and supporters of Standards based critical technology for the Free and Open Software revolution, has a unique opportunity to take on the active leadership role that the industry and the Community require, and in a form that encourages broad-based financial support. And now, of course, the details... Leon Shiman Associates Inc (SAI) 163 Tappan Street Brookline MA 02445 USA tel: (00)1.617.277.0087 Member of X.Org. Developers of MAS http://www.MediaApplicationServer.net From postmaster Thu Mar 20 06:21:45 2003 Received: from mwinf0302.wanadoo.fr (smtp4.wanadoo.fr [193.252.22.28]) by public.xfree86.org (8.12.8/8.12.8) with ESMTP id h2KELhVr063774 for ; Thu, 20 Mar 2003 06:21:44 -0800 (PST) (envelope-from luther@dpt-info.u-strasbg.fr) Received: from iliana (AStrasbourg-206-1-27-62.abo.wanadoo.fr [81.51.32.62]) by mwinf0302.wanadoo.fr (Postfix) with ESMTP id DD1DFC000230 for ; Thu, 20 Mar 2003 15:21:31 +0100 (CET) Received: from luther by iliana with local (Exim 3.36 #1 (Debian)) id 18w0vA-0000yz-00 for ; Thu, 20 Mar 2003 15:21:28 +0100 Date: Thu, 20 Mar 2003 15:21:24 +0100 To: forum@xfree86.org Subject: Re: [forum] XFree86 5.0 TODO Message-ID: <20030320142124.GA3651@iliana> References: <20030320095725.GA867@fairlite.demon.co.uk> <20030320114146.GA1375@iliana> <20030320123628.GE867@fairlite.demon.co.uk> <20030320125351.GA2534@iliana> <20030320131241.GG867@fairlite.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030320131241.GG867@fairlite.demon.co.uk> User-Agent: Mutt/1.5.3i From: Sven Luther X-Spam-Status: No, hits=-13.4 required=6.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.41 X-Spam-Level: Sender: forum-admin@XFree86.Org Errors-To: forum-admin@XFree86.Org X-BeenThere: forum@XFree86.Org X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: forum@XFree86.Org List-Help: List-Post: List-Subscribe: , List-Id: A public forum for discussion about the future of XFree86 List-Unsubscribe: , List-Archive: On Thu, Mar 20, 2003 at 01:12:41PM +0000, Alan Hourihane wrote: > > > > > 5. RandR. We now have rotation support, but not depth switching yet. This > > > > > still needs to be done. > > > > > > > > I personally am interested in dual/multi-head, and flexible > > > > configuration of viewports into a common framebuffer. I am not familiar > > > > with RandR, but i think it could be extended to allow dynamical head > > > > configuration or windows-zooming or other such functionality. > > > > > > I think multihead in a common framebuffer is doable in the current > > > infrastructure. > > > > You are saying that it should be possible to use RandR to switch the > > viewport of both heads dynamically, like we change resolutions today ? > > I'm not thinking RandR here. More a static approach by splitting the framebuffer > up into two portions, one for use as though it's an independent card. This is the static approach, we can already do this, i think, but what about being able to do dynamic changes ? The idea is to have a framebuffer zone we render to (with one XAA, one DRI and so on) and one, two or three independenct viewport into this. If you are not able to modify these viewports dynamically, you bar the door to features like screen mirroring (optionally with scaling) or windows zooming, which the matrox windows driver does already for example, and which are usefull, for people with sight problems or for doing presentations with a video projector for example. But then, you already read my arguments on the DRI mailing list, didn't you ? > Then XAA can share the graphics accelerator to write to both regions. I > understand this is the way of the mga driver that does it now. There'd > be a need for better framebuffer management to support depth switching for RandR > in this environment, which comes back to point 2. I am not so much interested by different depth, but by having one framebuffer of common depth, and be able to have two viewports looking into it freely, even overlapping or something such. > > > > > 8. Multiseat capability. Allowing multiple Xservers to run with independent > > > > > graphics cards, keyboards and mice on the same machine. > > > > > > > > What about running multiple seats on the different heads of a same video chip ? > > > > BTW, when the X server dies for whatever reason, it would take both > > seats with him, right ? > > Right. :(((( > > > > Anyway, for dual/multi-head on single graphic cards that support it, i > > > > would like to have us separate more the part related to the graphic chip > > > > from the part related to the output heads. Current multi-headed > > > > solutions (on the same chip) use a chip sharing trick, and the pEnt to > > > > store common information, but we could make this more formal, at least > > > > at the device driver level, and have things like preinit and part of the > > > > screeninit be done one time only for the entity, and then have multiple > > > > calls to modeinit for setting the viewports, the zooming, the > > > > outgoing resolution, the ddc info on the attached monitor and so on done > > > > per head. > > > > > > multihead on a common framebuffer is obviously chip specific, so a lot > > > of the details are specific to a driver. Again, for this, it should be > > > doable now. > > > > Yes, but not easily. The way i would do it currently is to set a virtual > > size that is the sum of both heads and inform the driver that the > > framebuffer is shared somehow. This would need the user to setup things. > > Another way of doing this is, in the driver, to wait that the > > information about both heads mode are given to the driver, and then sum > > them up and do a the framebuffer allocation then. This could be done in > > preinit, i think, but again, you would need to get access to the other > > head's framebuffer layout information and modify it, which is not the > > cleanest thing to do. If we are going to rework things, we could as well > > clean this up, no ? > > Take a closer look at the mga driver. Mmm, i did have a look, and, yes, it use the same kind of trick as you implemented in the glint driver for sharing the gamma between both pm3, does it not ? There are lot of places where there are checks for single/dual head (it doesn't support the parhelia triple head setup, i guess), and a refcount thingy to be able to do it only the first time. It is the same i have been doing in my new driver, but this is a hack, not a clean solution. If you look at these drivers, there are 3 phases : probe : you detect the hardware, share the entity, and allocate a pEnt if needed. preinit (a) : you parse the options, do some further chip and memory detection, and load modules. These are all things that can be common on both heads, after all, there is really no reason to detect the memory twice. Mostly this is done by checking the refcount, or using Isprimary or something such. preinit (b) : do some pixclock/mode/dpi settings. screeninit : set the actual video mode (first time we really write to the chip), save the previous state, and do some further initialization. It would be neater if we could do : probe : detect the hardware, count the heads. entityinit : the entity is shared by default, we do part (a) of preinit and the rest of the pEnt allocation done in probe currently. We also parse entity level option (from the device section, which is no more shared). We also reserve framebuffer memory for both upcoming heads. Called only one time per entity. preinit (or headinit) : we do part (b) of preinit, all things that are head specific. Here we detect the monitor, do per head clock/modes/whatever stuff, including parsing head specific options. Called once per head. ScreenInit : as usuel, called once per head, viewport information are separated between ingoing size (the framebuffer read) and outgoing size (the real mode), so we can do automatic zooming if the hardware supports it. This would allow for cleaner writing of drivers. Sure many of this is already possible, but in a hacky way. If we are planing about 5.0, let's do this cleanly, and think about it this way. Friendly, Sven Luther From postmaster Thu Mar 20 06:34:12 2003 Received: from smtp0.euronet.nl (smtp0.euronet.nl [194.134.35.141]) by public.xfree86.org (8.12.8/8.12.8) with ESMTP id h2KEYBVr036619 for ; Thu, 20 Mar 2003 06:34:11 -0800 (PST) (envelope-from Piethein.Strengholt@iie.nl) Received: from omnibook (node0202.vpt.adsl.euronet.nl [194.134.242.2]) by smtp0.euronet.nl (Postfix) with ESMTP id 9E68224832 for ; Thu, 20 Mar 2003 15:34:07 +0100 (MET) From: "Piethein Strengholt" To: Date: Thu, 20 Mar 2003 15:34:40 +0100 Message-ID: <000101c2eeed$d73352c0$1500a8c0@omnibook> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C2EEF6.38F7BAC0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=2.0 required=6.0 tests=HTML_50_70,HTML_FONT_COLOR_NAME,INVALID_MSGID, SPAM_PHRASE_00_01 version=2.41 X-Spam-Level: * Subject: [forum] Future of X ? Sender: forum-admin@XFree86.Org Errors-To: forum-admin@XFree86.Org X-BeenThere: forum@XFree86.Org X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: forum@XFree86.Org List-Help: List-Post: List-Subscribe: , List-Id: A public forum for discussion about the future of XFree86 List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C2EEF6.38F7BAC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Anyone could tell me what the future is of X now Keith Packard left the core team. I found Keith Packard quite interesting because he was really adding value to the project. So what's next? With managers like Gnome and KDE becoming more important we realy need a better underground!! So why not make the project more open? More developers and more supporters would really add some value. Maybe it's also an idea to split up the drivers from the project. Lets release Ati and Nvidia themselves. And why is there no roadmap ? I can't find anything about Xfree 5. News is very important to keep people's interrest in the project. And maybe Keith is right. A fork or maybe should Xfree be rewriten from scratch. X sounds very old to me and it's slow development is really keeping desktop users away from linux. So please make this project great! ------=_NextPart_000_0002_01C2EEF6.38F7BAC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Anyone could tell me what the future is of X now = Keith Packard left the core team. I found Keith Packard = quite interesting because he was really adding value to the project. So = what’s next?

 <= /font>

With managers = like Gnome and KDE becoming more important we realy need a better = underground!!

 <= /font>

So why not = make the project more open? More developers and more supporters would really add = some value. Maybe it’s also an idea to split up the drivers from the = project. Lets release Ati and Nvidia themselves.

 <= /font>

And why is = there no roadmap ? I can’t find anything about Xfree 5. News is very important to = keep people’s interrest in the project.

 <= /font>

And maybe = Keith is right. A fork or maybe should Xfree be rewriten = from scratch. X sounds very old to me and it’s slow development is = really keeping desktop users away from linux.

 

So please make this project great! =

 

 

------=_NextPart_000_0002_01C2EEF6.38F7BAC0-- From postmaster Thu Mar 20 06:49:42 2003 Received: from fairlite.demon.co.uk (fairlite.demon.co.uk [158.152.52.252]) by public.xfree86.org (8.12.8/8.12.8) with ESMTP id h2KEnfVr020742 for ; Thu, 20 Mar 2003 06:49:42 -0800 (PST) (envelope-from alanh@fairlite.demon.co.uk) Received: from fairlite.demon.co.uk (localhost.localdomain [127.0.0.1]) by fairlite.demon.co.uk (8.12.5/8.12.5) with ESMTP id h2KEnfI0001882 for ; Thu, 20 Mar 2003 14:49:41 GMT Received: (from alanh@localhost) by fairlite.demon.co.uk (8.12.5/8.12.5/Submit) id h2KEnfaW001880 for forum@XFree86.Org; Thu, 20 Mar 2003 14:49:41 GMT Date: Thu, 20 Mar 2003 14:49:41 +0000 From: Alan Hourihane To: forum@XFree86.Org Subject: Re: [forum] Future of X ? Message-ID: <20030320144941.GI867@fairlite.demon.co.uk> References: <000101c2eeed$d73352c0$1500a8c0@omnibook> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000101c2eeed$d73352c0$1500a8c0@omnibook> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-13.4 required=6.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.41 X-Spam-Level: Sender: forum-admin@XFree86.Org Errors-To: forum-admin@XFree86.Org X-BeenThere: forum@XFree86.Org X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: forum@XFree86.Org List-Help: List-Post: List-Subscribe: , List-Id: A public forum for discussion about the future of XFree86 List-Unsubscribe: , List-Archive: On Thu, Mar 20, 2003 at 03:34:40 +0100, Piethein Strengholt wrote: > And why is there no roadmap ? I can't find anything about Xfree 5. News > is very important to keep people's interrest in the project. Read the archives of this list, you've just missed a post about this. Alan. From postmaster Thu Mar 20 06:51:32 2003 Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by public.xfree86.org (8.12.8/8.12.8) with ESMTP id h2KEpVVr020862 for ; Thu, 20 Mar 2003 06:51:31 -0800 (PST) (envelope-from David.Bellot@inria.fr) Received: from imap-serv.inrialpes.fr (imap-serv.inrialpes.fr [194.199.18.72]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id h2KEpSE19036 for ; Thu, 20 Mar 2003 15:51:28 +0100 (MET) Received: from inria.fr (pastel.inrialpes.fr [194.199.21.71]) by imap-serv.inrialpes.fr (8.11.6/8.11.3/ImagV2) with ESMTP id h2KEpTd15020 for ; Thu, 20 Mar 2003 15:51:29 +0100 (MET) Message-ID: <3E79D4E0.5050305@inria.fr> Date: Thu, 20 Mar 2003 15:49:04 +0100 From: David Bellot User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: forum@XFree86.Org Subject: Re: [forum] Future of X ? References: <000101c2eeed$d73352c0$1500a8c0@omnibook> In-Reply-To: <000101c2eeed$d73352c0$1500a8c0@omnibook> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-10.6 required=6.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_LONG_SPARSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 X-Spam-Level: Sender: forum-admin@XFree86.Org Errors-To: forum-admin@XFree86.Org X-BeenThere: forum@XFree86.Org X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: forum@XFree86.Org List-Help: List-Post: List-Subscribe: , List-Id: A public forum for discussion about the future of XFree86 List-Unsubscribe: , List-Archive: > > > Anyone could tell me what the future is of X now Keith Packard left > the core team. I found Keith Packard quite interesting because he was > really adding value to the project. So what’s next? > > With managers like Gnome and KDE becoming more important we realy need > a better underground!! > > So why not make the project more open? More developers and more > supporters would really add some value. Maybe it’s also an idea to > split up the drivers from the project. Lets release Ati and Nvidia > themselves. > > And why is there no roadmap ? I can’t find anything about Xfree 5. > News is very important to keep people’s interrest in the project. > > And maybe Keith is right. A fork or maybe should Xfree be rewriten > from scratch. X sounds very old to me and it’s slow development is > really keeping desktop users away from linux. > I agree with you. Despite the fact that X is a very nice piece of code, X is old and need at least to be modified in order to take out all of those old features that nobody never wants to use. In fact, X should have a more light kernel, like an operating system, to be more scalable : from PDA to the latest SGI station. In fact, given the fact that more and more people are using the two leading desktop environment GNOME and KDE, there will be no need for a so-complex system like X. GNOME and KDE are encapsulating almost everything. I don't say that X must go away, but X has to be renewed to be more competitive ! * We need to have a better approach for drivers : ATI, NVidia, etc... need it ! * Where is the roadmap ? Is there a "private" roadmap ? * GCC was not a very open project. Now, GCC is open and has been partially rewritten. Everybody agrees to say that it was the best decision ! * What needs the average Joe user ? More features ? Speed ? Connectivity with a CRAY ZXY ? Good philosophy of open source? High framerate under UT2003 ? PDA compliance ? Mozilla and Evolution on its PDA ? Latest Radeon/GForce/etc... support (as soon as those cards are released) ? X rulez, but X is old, slow and development of X is more old and slow. Wake up, folks ! DB -- --------------------------------------------------- David Bellot, PhD SHARP project - INRIA Rhône-Alpes ZIRST - 655 avenue de l'Europe 38330 Montbonnot Saint Martin FRANCE Email : David.Bellot@inria.fr Web : http://www.inrialpes.fr/sharp/people/bellot --------------------------------------------------- From postmaster Thu Mar 20 06:54:18 2003 Received: from ms-dienst.rz.rwth-aachen.de (ms-1.rz.RWTH-Aachen.DE [134.130.3.130]) by public.xfree86.org (8.12.8/8.12.8) with ESMTP id h2KEsIVr020945 for ; Thu, 20 Mar 2003 06:54:18 -0800 (PST) (envelope-from nolden@kde.org) Received: from ms-1 (ms-dienst.rz.RWTH-Aachen.DE [134.130.3.132]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0HC100LO2YPBPF@ms-dienst.rz.rwth-aachen.de> for forum@XFree86.Org; Thu, 20 Mar 2003 15:53:36 +0100 (MET) Received: from relay.RWTH-Aachen.DE ([134.130.3.1]) by ms-1 (MailMonitor for SMTP v1.2.2 ) ; Thu, 20 Mar 2003 15:53:35 +0100 (MET) Received: from 192.168.1.10 (p5092781D.dip.t-dialin.net [80.146.120.29]) by relay.rwth-aachen.de (8.12.8/8.12.7) with ESMTP id h2KErXfv027961; Thu, 20 Mar 2003 15:53:34 +0100 (MET) Date: Thu, 20 Mar 2003 15:53:32 +0100 From: Ralf Nolden Subject: Re: [forum] Keith Packard issue In-reply-to: <200303201401.h2KE1OM04940@devserv.devel.redhat.com> To: forum@XFree86.Org, Alan Cox Message-id: <200303201553.32816.nolden@kde.org> Organization: The KDesktop Environment MIME-version: 1.0 Content-type: Text/Plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline Content-description: clearsigned data User-Agent: KMail/1.5.1 References: <200303201401.h2KE1OM04940@devserv.devel.redhat.com> X-Spam-Status: No, hits=-7.5 required=6.0 tests=IN_REP_TO,NOSPAM_INC,PGP_SIGNATURE,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_KMAIL version=2.41 X-Spam-Level: Sender: forum-admin@XFree86.Org Errors-To: forum-admin@XFree86.Org X-BeenThere: forum@XFree86.Org X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: forum@XFree86.Org List-Help: List-Post: List-Subscribe: , List-Id: A public forum for discussion about the future of XFree86 List-Unsubscribe: , List-Archive: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 20 March 2003 15:01, Alan Cox wrote: > > FYI: the Keith Packard issue is now on Slashdot.org. > > The "Keith Packard" issue or the XFree86 issue ? Correct. The post which is going on all news sites now is IMHO one of the most insulting posts that I ever read. Everyone who knows Keithp in person knows that we're discussing a thing here that is bugging literally everyone: developers from desktop projects like KDE and GNOME, distributors and UNIX derivates such as the BSD's and in the end, users and support companies who have to live with the stuff they get from XFree86. Compared to the development speed of projects like the Linux kernel or KDE, XFree86 lags behind *ages* and is not the most responsive at all. Keith has been one outstanding example with big ties to the community and acknowledgement for the problems that everyone suffers when it comes to XFree86 and tried to help with innovative ideas that just *have* to be solved on that layer of the OS (whatever Unix you use). My best read today was that people are thinking about releasing their own versions of graphics drivers because the CVS access to XFree86 is restricted to just about 15 people. This is just *unbeleivable*..... My personal 2 euro cents but I guess I'm expressing something that bugs most KDE hackers.... Ralf > > _______________________________________________ > Forum mailing list > Forum@XFree86.Org > http://XFree86.Org/mailman/listinfo/forum - -- We're not a company, we just produce better code at less costs. - -------------------------------------------------------------------- Ralf Nolden nolden@kde.org The K Desktop Environment The KDevelop Project http://www.kde.org http://www.kdevelop.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+edXsu0nKi+w1Ky8RAmdOAJ9qz9G9o0LynyaWO+/oRKFP9eXg0wCbBp2i vOGsAoWiwG6xnasqaJoMWoQ= =Yd1q -----END PGP SIGNATURE----- From postmaster Thu Mar 20 07:04:06 2003 Received: from fairlite.demon.co.uk (fairlite.demon.co.uk [158.152.52.252]) by public.xfree86.org (8.12.8/8.12.8) with ESMTP id h2KF44Vr021269 for ; Thu, 20 Mar 2003 07:04:05 -0800 (PST) (envelope-from alanh@fairlite.demon.co.uk) Received: from fairlite.demon.co.uk (localhost.localdomain [127.0.0.1]) by fairlite.demon.co.uk (8.12.5/8.12.5) with ESMTP id h2KF44I0001897 for ; Thu, 20 Mar 2003 15:04:04 GMT Received: (from alanh@localhost) by fairlite.demon.co.uk (8.12.5/8.12.5/Submit) id h2KF43fJ001895 for forum@XFree86.Org; Thu, 20 Mar 2003 15:04:03 GMT Date: Thu, 20 Mar 2003 15:04:03 +0000 From: Alan Hourihane To: forum@XFree86.Org Subject: Re: [forum] XFree86 5.0 TODO Message-ID: <20030320150403.GJ867@fairlite.demon.co.uk> References: <20030320095725.GA867@fairlite.demon.co.uk> <20030320114146.GA1375@iliana> <20030320123628.GE867@fairlite.demon.co.uk> <20030320125351.GA2534@iliana> <20030320131241.GG867@fairlite.demon.co.uk> <20030320142124.GA3651@iliana> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030320142124.GA3651@iliana> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-13.4 required=6.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.41 X-Spam-Level: Sender: forum-admin@XFree86.Org Errors-To: forum-admin@XFree86.Org X-BeenThere: forum@XFree86.Org X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: forum@XFree86.Org List-Help: List-Post: List-Subscribe: , List-Id: A public forum for discussion about the future of XFree86 List-Unsubscribe: , List-Archive: On Thu, Mar 20, 2003 at 03:21:24 +0100, Sven Luther wrote: > On Thu, Mar 20, 2003 at 01:12:41PM +0000, Alan Hourihane wrote: > > > > > > 5. RandR. We now have rotation support, but not depth switching yet. This > > > > > > still needs to be done. > > > > > > > > > > I personally am interested in dual/multi-head, and flexible > > > > > configuration of viewports into a common framebuffer. I am not familiar > > > > > with RandR, but i think it could be extended to allow dynamical head > > > > > configuration or windows-zooming or other such functionality. > > > > > > > > I think multihead in a common framebuffer is doable in the current > > > > infrastructure. > > > > > > You are saying that it should be possible to use RandR to switch the > > > viewport of both heads dynamically, like we change resolutions today ? > > > > I'm not thinking RandR here. More a static approach by splitting the framebuffer > > up into two portions, one for use as though it's an independent card. > > This is the static approach, we can already do this, i think, but what That's what I've already said that we can do this. > about being able to do dynamic changes ? The idea is to have a > framebuffer zone we render to (with one XAA, one DRI and so on) and one, > two or three independenct viewport into this. If you are not able to > modify these viewports dynamically, you bar the door to features like > screen mirroring (optionally with scaling) or windows zooming, which the > matrox windows driver does already for example, and which are usefull, > for people with sight problems or for doing presentations with a video > projector for example. But then, you already read my arguments on the > DRI mailing list, didn't you ? Nope, I must have missed that, but it comes down to framebuffer management as I've already said. I think I'll contact Ian Romanick to forward his current document here, regarding framebuffer management though. > > Then XAA can share the graphics accelerator to write to both regions. I > > understand this is the way of the mga driver that does it now. There'd > > be a need for better framebuffer management to support depth switching for RandR > > in this environment, which comes back to point 2. > > I am not so much interested by different depth, but by having one > framebuffer of common depth, and be able to have two viewports looking > into it freely, even overlapping or something such. It's still framebuffer management. > > > > > > 8. Multiseat capability. Allowing multiple Xservers to run with independent > > > > > > graphics cards, keyboards and mice on the same machine. > > > > > > > > > > What about running multiple seats on the different heads of a same video chip ? > > > > > > BTW, when the X server dies for whatever reason, it would take both > > > seats with him, right ? > > > > Right. > > :(((( > > > > > > Anyway, for dual/multi-head on single graphic cards that support it, i > > > > > would like to have us separate more the part related to the graphic chip > > > > > from the part related to the output heads. Current multi-headed > > > > > solutions (on the same chip) use a chip sharing trick, and the pEnt to > > > > > store common information, but we could make this more formal, at least > > > > > at the device driver level, and have things like preinit and part of the > > > > > screeninit be done one time only for the entity, and then have multiple > > > > > calls to modeinit for setting the viewports, the zooming, the > > > > > outgoing resolution, the ddc info on the attached monitor and so on done > > > > > per head. > > > > > > > > multihead on a common framebuffer is obviously chip specific, so a lot > > > > of the details are specific to a driver. Again, for this, it should be > > > > doable now. > > > > > > Yes, but not easily. The way i would do it currently is to set a virtual > > > size that is the sum of both heads and inform the driver that the > > > framebuffer is shared somehow. This would need the user to setup things. > > > Another way of doing this is, in the driver, to wait that the > > > information about both heads mode are given to the driver, and then sum > > > them up and do a the framebuffer allocation then. This could be done in > > > preinit, i think, but again, you would need to get access to the other > > > head's framebuffer layout information and modify it, which is not the > > > cleanest thing to do. If we are going to rework things, we could as well > > > clean this up, no ? > > > > Take a closer look at the mga driver. > > Mmm, i did have a look, and, yes, it use the same kind of trick as you > implemented in the glint driver for sharing the gamma between both pm3, > does it not ? There are lot of places where there are checks for > single/dual head (it doesn't support the parhelia triple head setup, i > guess), and a refcount thingy to be able to do it only the first time. It > is the same i have been doing in my new driver, but this is a hack, not > a clean solution. > > If you look at these drivers, there are 3 phases : > > probe : you detect the hardware, share the entity, and allocate a pEnt > if needed. > > preinit (a) : you parse the options, do some further chip and memory > detection, and load modules. These are all things that can be common > on both heads, after all, there is really no reason to detect the > memory twice. Mostly this is done by checking the refcount, or using > Isprimary or something such. > > preinit (b) : do some pixclock/mode/dpi settings. > > screeninit : set the actual video mode (first time we really write to > the chip), save the previous state, and do some further > initialization. > > It would be neater if we could do : > > probe : detect the hardware, count the heads. > > entityinit : the entity is shared by default, we do part (a) of > preinit and the rest of the pEnt allocation done in probe currently. > We also parse entity level option (from the device section, which is > no more shared). We also reserve framebuffer memory for both upcoming > heads. > Called only one time per entity. > > preinit (or headinit) : we do part (b) of preinit, all things that are > head specific. Here we detect the monitor, do per head > clock/modes/whatever stuff, including parsing head specific options. > Called once per head. > > ScreenInit : as usuel, called once per head, viewport information are > separated between ingoing size (the framebuffer read) and outgoing > size (the real mode), so we can do automatic zooming if the hardware > supports it. > > This would allow for cleaner writing of drivers. Sure many of this is > already possible, but in a hacky way. If we are planing about 5.0, let's > do this cleanly, and think about it this way. There's undoubtably some work to be done to clean up the driver interface. I'm not quite sure I completely understand what your splitting out above, but if you can base what your thinking on the DESIGN document in xc/programs/Xserver/hw/xfree86/doc/DESIGN and expand to the level of detail that exists in this document I could make more comments. Thanks Sven, Alan. From postmaster Thu Mar 20 07:08:27 2003 Received: from fairlite.demon.co.uk (fairlite.demon.co.uk [158.152.52.252]) by public.xfree86.org (8.12.8/8.12.8) with ESMTP id h2KF8PVr021445 for ; Thu, 20 Mar 2003 07:08:26 -0800 (PST) (envelope-from alanh@fairlite.demon.co.uk) Received: from fairlite.demon.co.uk (localhost.localdomain [127.0.0.1]) by fairlite.demon.co.uk (8.12.5/8.12.5) with ESMTP id h2KEmNI0001875; Thu, 20 Mar 2003 14:48:23 GMT Received: (from alanh@localhost) by fairlite.demon.co.uk (8.12.5/8.12.5/Submit) id h2KEmLSG001873; Thu, 20 Mar 2003 14:48:21 GMT Date: Thu, 20 Mar 2003 14:48:21 +0000 From: Alan Hourihane To: forum@XFree86.Org Cc: dri-devel Subject: Re: [forum] Re: [XFree86] Invitation for public discussion about the future of X Message-ID: <20030320144821.GH867@fairlite.demon.co.uk> References: <20030320001031.B7189@xfree86.org> <3E79A7FE.4070100@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E79A7FE.4070100@yahoo.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-13.4 required=6.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.41 X-Spam-Level: Sender: forum-admin@XFree86.Org Errors-To: forum-admin@XFree86.Org X-BeenThere: forum@XFree86.Org X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: forum@XFree86.Org List-Help: List-Post: List-Subscribe: , List-Id: A public forum for discussion about the future of XFree86 List-Unsubscribe: , List-Archive: On Thu, Mar 20, 2003 at 11:37:34 +0000, Keith Whitwell wrote: > XFree86 BOD wrote: > > >It has been brought to the attention of the XFree86 Core Team that one > >of its members, Keith Packard, has been actively (but privately) seeking > >out support for a fork of XFree86 that would be led by himself. He is > >also in the process of forming a by-invitation-only group of vested > >interests to discuss privately concerns he has about XFree86 and the > >future of X. He has consistently refused to even disclose these concerns > >within the context of the XFree86 Core Team, which makes his membership > >of that team unviable. As a consequence, Keith Packard is no longer a > >member of the XFree86 Core Team. > > What specifically does the XFree86 bod see as being wrong with the idea of > a 'by-invitation-only group' managing X server development? Isn't that > exactly what the core team & xfree86 BOD have been doing all along? Not exactly. Long ago, that was probably right, but these days you could probably see the Core Team as a bunch of committers to the CVS, obviously with their own areas of technical knowledge as well. And yes, we've met on occasion, but more in the reality of a coding frenzy to work on what we wanted to work on. More recently to talk about XFree86 5.0, of which I've sent what I wrote down to this list already. As for the BOD list, the Core Team doesn't know what goes on within that list either, not that it bothers me at all. > Maybe the core team & bod could explain what is being hinted as a new > spirit of openness and how that is proposed to effect the XFree86 > development process and strategy? Will it mean forinstance an end to the > sort of behind-closed-doors discussions that appear to have lead to this > announcement? You'd be surprised if you saw what is actually discussed on the Core Team lists. Not much at all, apart from recent events that led up to this email. I have to say, that a lot of the Core Team is still in the dark on why Keith decided to divert his attention away from XFree86 in the way that has transpired. We're as much in the dark as you Keith Whitwell (thought I'd better add your surname to avoid confusion). > Please forgive my somewhat cynical tone... The best strategy to fight a > fork would be to open up XFree & thereby make forking unnecessary. It > seems like that is whats being attempted, but can the leopard change its > spots? Sometimes I wonder if it knows it has them. Apart from when I was a teenager, I can remember having spots. > OK - some concrete proposals, with cynicism turned off: > - Make BOD minutes public That would be good, if I knew there were any minutes, which I don't think there are. > - Open all core team meetings to the public, and if feasible post > minutes, transcripts or even audio feeds. As for my 'XFree86 5.0 TODO' email, that's what was intentional. > - Extend CVS access to regular contributors. Use scripts or > whatever to control access to subtrees if you want. This comes up from time to time, and I'm sure will get discussed even more. I know there have been offers to others for CVS commit access, and some have refused and some have accepted. The consensus of who gets commit access has always been - if they show competance at sending patches in, then after a period of time, no doubt they'll get it. It's the same as the DRI, but with more of a prolonged period of evaluating that persons patches. I guess this 'prolonged' period, is the stickling point for most. > - Consider dropping the BOD and core team ideas in favour of an > elected committee. Examine recent trends in managing other large projects. As I mentioned above, think of the current Core Team, as a bunch of committers that review what comes into the various fixes/patches lists. Then extend the Core Team to specialized areas too in which they were forseen, and as such were granted CVS access. If the community see these teams as closed groups, then like you say, we disband these groups, or try and put out a better explanation of what they mean. > Just generally get down off your high horses and accept that the developers > out there won't wreck xfree86 if you let them participate & accept them as > equals... I understand this point, and it comes down to the fact that there still needs to be some level of control of who gets commit access, just like any other open source project. It's probably not moving quick enough for some though. > Of course, if xfree starts accepting more developers, it will make it > harder for us in the dri tree as we tend to benefit from xfree's > exclusionary practices -- developers find it easier to get cvs access for > DRI than XFree86, so we pick up some talented developers that get fed up of > waiting for patches to be applied to xfree cvs. But then again, what is > the dri tree but a friendly fork to workaround for xfree's closed > development methodology? If xfree really opened itself up, the first thing > they'd do is extend an invitation to merge with the dri project, right? > Maybe that's the acid test, or maybe it's whether we'd accept... Then shut up, if you don't want your DRI developers nicked :0) Only kidding. Alan. From postmaster Thu Mar 20 07:16:12 2003 Received: from gatemaster.ivimey.org (wotug.org [194.106.52.201]) by public.xfree86.org (8.12.8/8.12.8) with ESMTP id h2KFGBVr013428 for ; Thu, 20 Mar 2003 07:16:12 -0800 (PST) (envelope-from Ruth.Ivimey-Cook@ivimey.org) Received: from robinton.ivimey.org ([192.168.0.5]) by gatemaster.ivimey.org with esmtp (Exim 4.10) id 18w1m5-0000C7-00 for forum@XFree86.Org; Thu, 20 Mar 2003 15:16:09 +0000 Message-Id: <5.2.0.9.0.20030320145403.00baf910@mailhost.ivimey.org> X-Sender: ruthc@mailhost.ivimey.org X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 20 Mar 2003 15:16:02 +0000 To: forum@XFree86.Org From: Ruth Ivimey-Cook Subject: Re: [forum] XFree86 5.0 TODO Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.6 required=6.0 tests=SPAM_PHRASE_00_01 version=2.41 X-Spam-Level: Sender: forum-admin@XFree86.Org Errors-To: forum-admin@XFree86.Org X-BeenThere: forum@XFree86.Org X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: forum@XFree86.Org List-Help: List-Post: List-Subscribe: , List-Id: A public forum for discussion about the future of XFree86 List-Unsubscribe: , List-Archive: >So, to spark discussions, here it is.... >1. Redesign of XAA, >2. FBManager extensions. Neither of these seem to me to be urgent requirements, but I guess that's my lack of info at fault. >3. Xlib locale removal. By removing all the Xlc code from libX11 and see >if we can layer it on top of iconv. Need to discuss the advantages and >disadvantages of such a task. The main benefit being unicode support? Otherwise, what? >4. DGA - do we leave in, or do we shelve it ? Leave, for the moment. >5. RandR. We now have rotation support, but not depth switching yet. This >still needs to be done. IMO required ASAP, at least for single-head. >6. PseudoColor emulation. Egbert Eich has written some preliminary code >for this, and we're hoping he'll be able to release it soon. Is there a known hold-up to this work? Presumably it just extends the number of visuals available to truecolor hardware? >7. Hot Plugging of devices. Displays, Keyboards, Mice. This is obviously >tricky when running multiple Xservers on the same machine. How do you >correlate which device is plugged in, to which Xserver etc. Definitely good. Lets solve the problem for one server first; multiple servers will I guess have to use some sort of ID or port-matching technique, which is horribly platform dependent (at least in how to get hold of such info). >8. Multiseat capability. Allowing multiple Xservers to run with >independent graphics cards, keyboards and mice on the same machine. What is holding this up? It seems as if it ought to be a no-brainer? >9. Xc/Xr - A postscript rendering library for the RENDER extension >replacing Xlib drawing routines. What status is this? Is there a demand? How does it differ in capability from the Display PostScript code. >10. Window translucency. Yes!. Better alpha-blend control in general. >11. XFixes extension. For? >12. Gamma corrected RENDER For? >13. Potential DIX/DDX changes. In the interface position, or structure, or what? 14. Native SVG support. -- SVG Extension? 15. Improved user interface/properties access to the server, esp. to reconfigure it dynamically (e.g. extending xset). Regards, Ruth From postmaster Thu Mar 20 07:20:02 2003 Received: from web11301.mail.yahoo.com (web11301.mail.yahoo.com [216.136.131.204]) by public.xfree86.org (8.12.8/8.12.8) with SMTP id h2KFK2Vr060466 for ; Thu, 20 Mar 2003 07:20:02 -0800 (PST) (envelope-from agd5f@yahoo.com) Message-ID: <20030320152001.78921.qmail@web11301.mail.yahoo.com> Received: from [146.135.61.199] by web11301.mail.yahoo.com via HTTP; Thu, 20 Mar 2003 07:20:01 PST Date: Thu, 20 Mar 2003 07:20:01 -0800 (PST) From: Alex Deucher To: forum@XFree86.Org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.6 required=6.0 tests=SPAM_PHRASE_00_01 version=2.41 X-Spam-Level: Subject: [forum] XFree86 5.0 TODO Sender: forum-admin@XFree86.Org Errors-To: forum-admin@XFree86.Org X-BeenThere: forum@XFree86.Org X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: forum@XFree86.Org List-Help: List-Post: List-Subscribe: , List-Id: A public forum for discussion about the future of XFree86 List-Unsubscribe: , List-Archive: Some other suggestions: - integrating Gatos code - perhaps provideing better multimedia interfaces, maybe some thing that integrates Xv, XvMC, etc. Providing YUV surfaces using both the overlay engine and OpenGL textures. - as Sven mentioned better Dualhead support; Support for Dualhead DRI for both multi-card and single card multi-head scenarios. being able to dymanically switch the video overlay hardware to the head a video is being played on instead of binding it to a single head for hardware that supports it. - a more dynamic X server. The ability to change configs, change dualhead layouts, tv out, etc. on the fly. User definable hot buttons to change configs, outputs etc. - improved power mangement support (maybe start with Michel/Charl's radeon suspend patch) - integrating DMX - Release more often! smaller releases, or releasing updates to just certain modules, etc. Alex ----------------------------------------- Well, As this forum is for discussing all X stuff, here goes with a few notes from an XFree86 Core Team meeting from a little while back. So in the spirit of openness I thought I should discuss it here. This is stuff that we can think of that needs doing for XFree86 5.0, but by no means is it limited to this list or even guarantee'ing anything on the list will make it for 5.0. So, to spark discussions, here it is.... 1. Redesign of XAA, so that multiple depth pixmaps can be stored in offscreen memory and the creation of a new directive - called the XAASurface. There will undoubtably be driver work involved to port to the new interface. The techinical lead on this is Mark Vojkovich. I believe Mark has a substantial portion of this done, if not all. 2. FBManager extensions. This still needs furthur thought to encompass the requirements of all bases, but, the DRI is one that needs much more flexible memory management of the framebuffer. Secondly, it's been requested before for linear allocation, rather than the current area allocation code for some Xv implementations. 3. Xlib locale removal. By removing all the Xlc code from libX11 and see if we can layer it on top of iconv. Need to discuss the advantages and disadvantages of such a task. 4. DGA - do we leave in, or do we shelve it ? 5. RandR. We now have rotation support, but not depth switching yet. This still needs to be done. 6. PseudoColor emulation. Egbert Eich has written some preliminary code for this, and we're hoping he'll be able to release it soon. 7. Hot Plugging of devices. Displays, Keyboards, Mice. This is obviously tricky when running multiple Xservers on the same machine. How do you correlate which device is plugged in, to which Xserver etc. 8. Multiseat capability. Allowing multiple Xservers to run with independent graphics cards, keyboards and mice on the same machine. 9. Xc/Xr - A postscript rendering library for the RENDER extension replacing Xlib drawing routines. 10. Window translucency. 11. XFixes extension. 12. Gamma corrected RENDER 13. Potential DIX/DDX changes. Any other topics, please bring up for discussion. __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com From postmaster Thu Mar 20 07:35:18 2003 Received: from ms-dienst.rz.rwth-aachen.de (ms-1.rz.RWTH-Aachen.DE [134.130.3.130]) by public.xfree86.org (8.12.8/8.12.8) with ESMTP id h2KFZIVr021304 for ; Thu, 20 Mar 2003 07:35:18 -0800 (PST) (envelope-from nolden@kde.org) Received: from ms-2 (ms-2 [134.130.3.131]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0HC200LM70EOXK@ms-dienst.rz.rwth-aachen.de> for forum@XFree86.Org; Thu, 20 Mar 2003 16:30:25 +0100 (MET) Received: from relay.RWTH-Aachen.DE ([134.130.3.1]) by ms-2 (MailMonitor for SMTP v1.2.2 ) ; Thu, 20 Mar 2003 16:30:24 +0100 (MET) Received: from 192.168.1.10 (p5092781D.dip.t-dialin.net [80.146.120.29]) by relay.rwth-aachen.de (8.12.8/8.12.7) with ESMTP id h2KFUMfv004558; Thu, 20 Mar 2003 16:30:23 +0100 (MET) Date: Thu, 20 Mar 2003 16:30:21 +0100 From: Ralf Nolden Subject: Re: [forum] XFree86 5.0 TODO In-reply-to: <5.2.0.9.0.20030320145403.00baf910@mailhost.ivimey.org> To: forum@XFree86.Org, Ruth Ivimey-Cook Message-id: <200303201630.22034.nolden@kde.org> Organization: The KDesktop Environment MIME-version: 1.0 Content-type: Text/Plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline Content-description: clearsigned data User-Agent: KMail/1.5.1 References: <5.2.0.9.0.20030320145403.00baf910@mailhost.ivimey.org> X-Spam-Status: No, hits=-11.0 required=6.0 tests=IN_REP_TO,NOSPAM_INC,PGP_SIGNATURE,QUOTED_EMAIL_TEXT, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_KMAIL version=2.41 X-Spam-Level: Sender: forum-admin@XFree86.Org Errors-To: forum-admin@XFree86.Org X-BeenThere: forum@XFree86.Org X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: forum@XFree86.Org List-Help: List-Post: List-Subscribe: , List-Id: A public forum for discussion about the future of XFree86 List-Unsubscribe: , List-Archive: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 20 March 2003 16:16, Ruth Ivimey-Cook wrote: > >9. Xc/Xr - A postscript rendering library for the RENDER extension > >replacing Xlib drawing routines. > > What status is this? Is there a demand? How does it differ in capability > from the Display PostScript code. I think MacOS X does most of the animation stuff with postscript (the minimizing of windows for example). The usage of such features need to be very transparently and easily made through the toolkits. Don't know any specifics but I think there is a demand to get such cool features like OS X has. Ralf - -- We're not a company, we just produce better code at less costs. - -------------------------------------------------------------------- Ralf Nolden nolden@kde.org The K Desktop Environment The KDevelop Project http://www.kde.org http://www.kdevelop.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+ed6Ou0nKi+w1Ky8RAvxhAJ0YPYD3aVTZM3Sz+x01vrQdOmzUmwCgkmRQ R6PYcdvaQFG0zyHnsfCcxqI= =kFl5 -----END PGP SIGNATURE----- From postmaster Thu Mar 20 07:49:28 2003 Received: from fries.net (root@ns0.fries.net [66.210.106.26]) by public.xfree86.org (8.12.8/8.12.8) with ESMTP id h2KFnRVr053841 for ; Thu, 20 Mar 2003 07:49:28 -0800 (PST) (envelope-from todd@shadow.fries.net) Received: from shadow.fries.net (todd@localhost.fries.net [IPv6:::1]) by fries.net (8.12.8/8.12.8) with ESMTP id h2KFjKjg004672 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Thu, 20 Mar 2003 09:45:20 -0600 (CST) Received: (from todd@localhost) by shadow.fries.net (8.12.8/8.12.8/Submit) id h2KFjIT0006245 for forum@xfree86.org; Thu, 20 Mar 2003 09:45:18 -0600 (CST) Date: Thu, 20 Mar 2003 09:45:18 -0600 From: "Todd T. Fries" To: forum@xfree86.org Message-ID: <20030320154518.GG9122@openbsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.99i X-Operating-System: OpenBSD shadow.fries.net 3.3 GENERIC X-Spam-Status: No, hits=-6.7 required=6.0 tests=SIGNATURE_LONG_SPARSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT version=2.41 X-Spam-Level: Subject: [forum] thoughts Sender: forum-admin@XFree86.Org Errors-To: forum-admin@XFree86.Org X-BeenThere: forum@XFree86.Org X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: forum@XFree86.Org X-Reply-To: todd@fries.net List-Help: List-Post: List-Subscribe: , List-Id: A public forum for discussion about the future of XFree86 List-Unsubscribe: , List-Archive: I have wishes for the future of XFree86 that I believe I am incapable of implementing; perhaps with some coaching and luck at finding free time may change that, but suffice it to say I am responding to the call for future desires of X. Future direction I personally would like to see: - lower memory footprint - more optional modules/protocols - grandfathering of old protocol support, perhaps via an 'old' module, to assist on the above - more effort at bringing 'legacy' drivers from 3.3.6 to 4.x - support for IPv6 - no change in license terms (free for all, including Keith to do his own thing) I believe Keith Packard's kdrive does the first two (are there _any_ plans to support IPv6 in X?). I would like to thank everyone for their hard work on X that has brought us to this point. Without it, many of us may not even be interested in UNIX as a desktop + server os. Thanks for listening, -- Todd Fries .. todd@fries.net Free Daemon Consulting, LLC Land: 405-748-4596 http://FreeDaemonConsulting.fries.net Mobile: 405-203-6124 "..in support of free software solutions." Key fingerprint: 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A Key: http://todd.fries.net/pgp.txt (last updated 2003/03/13 07:14:10) From postmaster Thu Mar 20 07:54:29 2003 Received: from mwinf0403.wanadoo.fr (smtp3.wanadoo.fr [193.252.22.27]) by public.xfree86.org (8.12.8/8.12.8) with ESMTP id h2KFsSVr072411 for ; Thu, 20 Mar 2003 07:54:29 -0800 (PST) (envelope-from luther@dpt-info.u-strasbg.fr) Received: from iliana (AStrasbourg-206-1-27-62.abo.wanadoo.fr [81.51.32.62]) by mwinf0403.wanadoo.fr (Postfix) with ESMTP id 0247750003B3 for ; Thu, 20 Mar 2003 16:54:17 +0100 (CET) Received: from luther by iliana with local (Exim 3.36 #1 (Debian)) id 18w2Mx-0001Hx-00 for ; Thu, 20 Mar 2003 16:54:15 +0100 Date: Thu, 20 Mar 2003 16:54:14 +0100 To: forum@xfree86.org Subject: Re: [forum] XFree86 5.0 TODO Message-ID: <20030320155414.GA4547@iliana> References: <20030320095725.GA867@fairlite.demon.co.uk> <20030320114146.GA1375@iliana> <20030320123628.GE867@fairlite.demon.co.uk> <20030320125351.GA2534@iliana> <20030320131241.GG867@fairlite.demon.co.uk> <20030320142124.GA3651@iliana> <20030320150403.GJ867@fairlite.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030320150403.GJ867@fairlite.demon.co.uk> User-Agent: Mutt/1.5.3i From: Sven Luther X-Spam-Status: No, hits=-13.4 required=6.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.41 X-Spam-Level: Sender: forum-admin@XFree86.Org Errors-To: forum-admin@XFree86.Org X-BeenThere: forum@XFree86.Org X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: forum@XFree86.Org List-Help: List-Post: List-Subscribe: , List-Id: A public forum for discussion about the future of XFree86 List-Unsubscribe: , List-Archive: On Thu, Mar 20, 2003 at 03:04:03PM +0000, Alan Hourihane wrote: > On Thu, Mar 20, 2003 at 03:21:24 +0100, Sven Luther wrote: > > about being able to do dynamic changes ? The idea is to have a > > framebuffer zone we render to (with one XAA, one DRI and so on) and one, > > two or three independenct viewport into this. If you are not able to > > modify these viewports dynamically, you bar the door to features like > > screen mirroring (optionally with scaling) or windows zooming, which the > > matrox windows driver does already for example, and which are usefull, > > for people with sight problems or for doing presentations with a video > > projector for example. But then, you already read my arguments on the > > DRI mailing list, didn't you ? > > Nope, I must have missed that, but it comes down to framebuffer management > as I've already said. I think I'll contact Ian Romanick to forward his > current document here, regarding framebuffer management though. Yes and no, the main idea is to separate the framebuffer management thingy (either for framebuffer memory and for offscreen pixmaps or other succ) from the viewports. You have the framebuffer, where the graphic core/processor renders to, and you have then one, two or more viewports that allow you (the human looking at the screen) to look at the content of this framebuffer, these viewports correspond to the DAC or Digital Ports, or even Video Ports, that allow you to see the content of the framebuffer. These viewports take a source zone (x/y position of the framebuffer in the virtual memory + width/height) and an outgoing mode for the monitor, flatpanel, etc. And it is this viewport setting that does not come down to framebuffer management, and for which i hope we can come up with a propper solution. > > This would allow for cleaner writing of drivers. Sure many of this is > > already possible, but in a hacky way. If we are planing about 5.0, let's > > do this cleanly, and think about it this way. > > There's undoubtably some work to be done to clean up the driver interface. :))) > I'm not quite sure I completely understand what your splitting out above, > but if you can base what your thinking on the DESIGN document in > xc/programs/Xserver/hw/xfree86/doc/DESIGN and expand to the level of > detail that exists in this document I could make more comments. Ok, i will try to come up with such a document, i will need some tim for it though, and, well, i am mostly familiar only with the driver part, not with whatever is done above the driver. Friendly, Sven Luther From postmaster Thu Mar 20 08:03:30 2003 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by public.xfree86.org (8.12.8/8.12.8) with ESMTP id h2KG3UVr072828 for ; Thu, 20 Mar 2003 08:03:30 -0800 (PST) (envelope-from sndirsch@suse.de) Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 9DF9014B19 for ; Thu, 20 Mar 2003 17:03:29 +0100 (MET) X-Authentication-Warning: shannon.suse.de: sndirsch set sender to sndirsch@suse.de using -f Date: Thu, 20 Mar 2003 17:03:26 +0100 From: Stefan Dirsch To: forum@XFree86.Org Message-ID: <20030320160326.GA7772@shannon.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-4.5 required=6.0 tests=MAILTO_TO_SPAM_ADDR,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT,X_AUTH_WARNING version=2.41 X-Spam-Level: Subject: [forum] Bugzilla Mails Sender: forum-admin@XFree86.Org Errors-To: forum-admin@XFree86.Org X-BeenThere: forum@XFree86.Org X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: forum@XFree86.Org List-Help: List-Post: List-Subscribe: , List-Id: A public forum for discussion about the future of XFree86 List-Unsubscribe: , List-Archive: Hi It's more a minor issue. Is it really required to send all Bugzilla mails to xfree86@xfree86.org? Wouldn't it be sufficient to send these mails to assignee, reporter and persons in Cc: ? Regards, Stefan Public Key available ---------------------------------------------------- Stefan Dirsch (Res. & Dev.) SuSE Linux AG Tel: 0911-740530 Deutschherrnstr. 15-19 FAX: +49 911 741 77 55 D-90429 Nuernberg http://www.suse.de Germany ---------------------------------------------------- From postmaster Thu Mar 20 08:11:53 2003 Received: from ms-dienst.rz.rwth-aachen.de (ms-1.rz.RWTH-Aachen.DE [134.130.3.130]) by public.xfree86.org (8.12.8/8.12.8) with ESMTP id h2KGBrVr076627 for ; Thu, 20 Mar 2003 08:11:53 -0800 (PST) (envelope-from nolden@kde.org) Received: from ms-2 (ms-2 [134.130.3.131]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0HC200M3B26Q85@ms-dienst.rz.rwth-aachen.de> for forum@XFree86.Org; Thu, 20 Mar 2003 17:08:50 +0100 (MET) Received: from relay.RWTH-Aachen.DE ([134.130.3.1]) by ms-2 (MailMonitor for SMTP v1.2.2 ) ; Thu, 20 Mar 2003 17:08:50 +0100 (MET) Received: from 192.168.1.10 (p5092781D.dip.t-dialin.net [80.146.120.29]) by relay.rwth-aachen.de (8.12.8/8.12.7) with ESMTP id h2KG8mfv011268; Thu, 20 Mar 2003 17:08:49 +0100 (MET) Date: Thu, 20 Mar 2003 17:08:48 +0100 From: Ralf Nolden Subject: Re: [forum] XFree86 5.0 TODO In-reply-to: <20030320152001.78921.qmail@web11301.mail.yahoo.com> To: forum@XFree86.Org, Alex Deucher Message-id: <200303201708.48146.nolden@kde.org> Organization: The KDesktop Environment MIME-version: 1.0 Content-type: Text/Plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline Content-description: clearsigned data User-Agent: KMail/1.5.1 References: <20030320152001.78921.qmail@web11301.mail.yahoo.com> X-Spam-Status: No, hits=-11.0 required=6.0 tests=IN_REP_TO,NOSPAM_INC,PGP_SIGNATURE,QUOTED_EMAIL_TEXT, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_KMAIL version=2.41 X-Spam-Level: Sender: forum-admin@XFree86.Org Errors-To: forum-admin@XFree86.Org X-BeenThere: forum@XFree86.Org X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: forum@XFree86.Org List-Help: List-Post: