Re: [CFT] Xorg 7.7 ready for testing!

From: Konstantin Belousov <kostikbel_at_gmail.com>
Date: Thu, 7 Jun 2012 17:07:43 +0300
On Thu, Jun 07, 2012 at 08:37:53PM +0800, Martin Wilke wrote:
> Hi Fans,
> 
> The FreeBSD Xorg Team is pleased to announce Xorg 7.7 Release. We are
> very happy to be able to Call for testing shortly after the Xorg team
> annouced 7.7 release. This CFT is also open for discussion on how we
> should move forward with xorg release as we are facing some issues and
> we would like to ask for your opinion. Right now we have 2 existing
> xorg versions in our Ports Tree. The situation is quite bad due to our
> poor graphic card support. That means we do not have much choice but to
> take it as how it is now. But with regards to mesa support, we have to
> face some new challanges.
> 
> With the new mesa 8.0 release, accelerated support for a number of
> older graphic cards was dropped. At the moment we are not sure how to
> deal with that.We are thinking of just replacing mesa 7.11 with 8.0 or
> making a new flag like WITH_MESA= 7.11.2 / 8.0 in combination with
> WITH_NEW_XORG, and let the mesa 7.6.1 set as default together with the
> old xorg version. Obviosly the latter option make the already complex
> situation more complex. The problem is, users, especially  the new ones
> can easily get confused with it. Another issue is, the packages.We
> can't deliver a package set with the new Xorg releases. This means
> users with new hardware will have to compile everything by themselves.
> Though I'm totally fine with compiling, not everyone has the CPU power
> to compile everything. What I'm trying to say is, I would love to see
> the newer xorg released as the default version, but i know this will
> break a lot of old hardware. The thing is, when we want to try to
> become a Modern Operating System, I dont see any other way to make the
> new xorg as default but to give Users the chance to compile the old
> xorg with a flag like WITH_OLD_XORG.
[Flag weaving follows]

I think it is reasonable and inevitable to drop support for anything
except Intel, ATI and NVidia. This seems to be a route taken by the
upstream. Currently, ATI is big problem, Intel is less so, and NVidia
should work except that we do not have sources for code that works.

The upstream decision to handle lesser cards is to provide small
kernel-side KMS-only drivers, and use xf86-video-modesetting (if I
remember the name of the ddx driver right) for all of them. Driver will
use in-kernel KMS to get video mode going, and only procide software
acceleration.

I will not port these miriad of KMS drivers, I did hoped that initial
Intel port and KMS infrastructure would cause some following from other
people starting contributing for our GPU support.

To not sink completely with Xorg/GPU etc, we need:
- a porting work for ATI kernel code (there is initial work done already,
  and I did promised to port TTM, hopefully will do it).
- continue the work of importing Linux changes for generic DRM infrastructure
  and Intel driver. I somewhat run out of stem for this activity.
- start porting other kernel drivers from Linux. E.g. GMA500, generic
  fbdev KMS driver, matrox etc.

I simply cannot keep up with all this tasks alone, and already having spent
more then a year of my life with that, I want to delegate at last part of the
load to interested (and capable) people. Please, show the work accomplished,
feel free to ask the tecnhical questions about doing it, use the lists
for communication. And no, I do not need advises how to do _my_ part of
the work.

Thank you.

Received on Thu Jun 07 2012 - 12:08:01 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:27 UTC