[forum] GGI might be the way...
Peter Karlsson
forum@XFree86.Org
Sun, 23 Mar 2003 01:19:08 +0100 (CET)
--- David Jeske <jeske@chat.net> skrev: > Since
you're all considering how to take the next
> step with X/Xfree, I
> think you should consider absorbing and adopting
> GGI. Even if you have
> some political beef with GGI or it's implementation
> choices -- please
> consider the motivations below carefully.
>
> HEALTH WARNING: I make several references to how
> Microsoft has handled
> things because we all know that they have (a) great
> driver support,
> and (b) rippin fast graphics performance. If you
> have some mental
> block which makes you mad when reading about someone
> saying Microsoft
> has done something right, for your own health,
> please do not read any
> futher.
Can't help myself. Ugh, argh... ;-)
>
> 1) Third party driver distribution needs to be the
> norm, not an
> afterthought. GGI _is_ a video driver model which
> is not
> limited to use inside X.
I sincerely hope not the 3rd party driver becomes the
norm:
3rd Party support: Hello, how may I help you?
User: Hello, I have a problem with your gfx card; I
can't get it to work with my configuration X/Y/Z.
3rd Party support: Oh, I'm sorry we do not support
that configuration, we only support X/X/X
configuration.
User: Oh, then I'm screwed...
3rd Party support: Tough...
With the current solution I can if I choose my
hardware carefully do almost anything I want to do
with it (see below).
>
> There is alot of anti-third party anything
> sentiment in the open
> source community. Often this seems to revolve
> around the "presumed
> evil nature" of distributing binary software. If
> you ask any
> systems architect (in any field), they will tell
> you that
Nvidia, need I say more... I got careless one day and
bought an barebone (mini-pc) from Shuttle with nforce2
chipset. To get it fully working with Linux I need to
download binary drivers from nvidias homepage to get
the pc fully operational. The problem is that I can't
download it since the onboard NIC is nvidia... That's
catch 22 for you... Furthermore I don't use the
built-in geforce4 but put in an ati radeon card
instead and the nvidia drivers don't support agpgart
with other brands than their own... See
http://home.t-online.de/home/Johannes.Deisenhofer/nforce2linux.html
> centralized systems do not work, and "software
> development" is no
> exception to thus rule. It does not matter if you
> have 250
> volunteer developers, or 15,000 employed
> developers in Redmond, if
> you want to support third-party hardware (or
> software), you HAVE to
> let the third parties do it themselves.
>
> Here is an example of the perspective shift
> necessary. Recently,
> Keith explained that users with newly supported
> Radeon chips had to
> wait for the Feb 2003 release of Xfree under the
> heading "slow
> release schedules". This entire mindset is
> flawed. There is *NO*
> release schedule for Xfree which would be fast
> enough. XFree is
> packaged with RedHat at a specific time and
> RedHat is not about to
> go cut a new master every time Xfree does a
> release. Furthermore,
> users simple do not upgrade their Xfree... EVER.
I use linuxfromscratch(.org), which is exactly what it
says (it's not a distro which means building and
upgrading from XFree-sources). Besides not everyone
uses redhat or perhaps uses a bsd-os which I am not
that familiar. Need I say more...?
> They get a new
> Xfree on a new machine when a new Linux
> distribution comes out. The
> only way to get them support for newer hardware
> is to stop
> expecting it to be provided by in an XFree
> release. Even better
> would be to stop expecting it to be provided by
> the XFree team.
>
> The open source community needs to stop throwing
> away all the
> valuable lessons learned over years of software
> industry growth. If
> we want to have the quickest and best driver
> support, we need to
> EMPOWER the hardware manufacturers to provide
> their own drivers by
> giving them a standards based development model
> which is (a) not a
> moving target, and (b) has forward compatibility
> with new core
> releases, whether that is XFree, the kernel, etc.
> That forward
> compatibility should work for at LEAST 2 years.
>
> GGI has all of these goals in mind, and has done
> a reasonable job
> so far given that very few people are using it.
>
> 2) Moving to a direct rendering model WILL increase
> performance. GGI
> provides this model, and also lets us run X
> today!
>
> I have read much argument about whether or not
> the architecture of
> X is responsible for some of the video
> performance delta between
> Windows and *nix. Some blame the drivers, some
> blame the wire
> protocol, others blame the *nix kernel
> schedulers. The fact is that
> improvement in any of these area can improvement
> performance. The
> fact is that direct rendering IS faster than
> networked
> rendering. Period. Can networked rendering be
> "fast enough"?
> Probably, but why settle for "fast enough"?
>
> The beauty of the X/GGI model is that it allows
> us to mix and match
> direct-rendering with the X wire-protocol. It's a
> simple migration
> path forward, providing a model which is not
> dissimilar from
> Microsoft's GDI/DirectX split. Although neither
> of those has a wire
> protocol, DirectX was gradually made available to
> improve
> performance of applications which need direct
> rendering. Now
> DirectX is the core of the entire rendering model
> on Windows.
>
> GGI could help facilitate the same type of change
> here.
I don't mind if GGI is an option for those who want it
but don't touch the X network rendering, which I use
quite frequently (several times a day)...
>
> 3) GGI provides modern features today.
>
> For example, it allows support for multiheaded
> displays running
> different video hardware with drag across. It
> already runs on small
> mobile devices. It supports 3d rendering (ala
> Direct3d) . It
> supports video overlay with hardware colorspace
> conversion (ala
> DirectDraw surfaces). It supports color blending
> (alpha). It
> supports direct hardware blitter access (ala
> DirectDraw). It
> supports an input handling driver model (ala
> DirectInput).
>
> It also supports features that Windows can't
> touch, such as
> virtualization of the drawing interface. Plus,
> GGI also runs on
> Windows under DirectX!
>
> 4) Xf86Config files must die
NO,NO,NO!!! It's needed for customisations which is
the unix way (at least I think so). DDC, or whatever
it's called, which is needed for X (and m$windows) to
correctly configure the screen, is dependent on a
traditional hookup (standard 15-pin vga) or perhaps an
usb-connection to the screen; I don't really know
since I use bnc to connect to my current screen (the
screen does not have a d-sub, bnc is preferable
anyway). I _have_ to use the XF86Config-file.
>
> *nix is at a cusp point where it could soon gain
> widespread
> adoption. However, it isn't going to happen if
> users have to hand
> edit configuration files to get basic things to
> work.
>
> Recently I was told a story about how ironically
> silly one new
> "graphical mouse chooser" dialog is. Apparently
> you can do almost
> everything with the dialog via Keyboard except
> expand nodes in the
> tree. The result, this user had to once again
> drop to command line
> and edit the config file by hand to set this
> source for his mouse.
I like the cli, or shell if you will... But I know
people who don't. Isn't this about choice. :-)
>
> The real problem here is NOT the broken mouse
> config program. The
> problem is that someone thinks there should be a
> mouse chooser
> dialog! There is no mouse "chooser" dialog on
> Windows or
> MacOS. They just figure out where my mouse is. If
> I also plug in a
> USB mouse, guess what? I just have two working
> mice. Clearly there
> is no need for the user to have to poke around to
> make a mouse
> work. These other systems merely let me set the
> mouse speed, double
> click speed, etc. None of these are required for
> the mouse to move
> the pointer happily across the screen.
>
> We also don't need a configuration file to say
> what the valid
> switchable resolutions or color depths are, X
> should just show the
> user all the available resolutions in a display
> config panel and
What config panel? Do I _have_ to use gnome or kde to
be able to use this config app(let)?
> let him switch on the fly like every other modern
> operating
I believe there is a graphical configuration
application that comes with XFree. Maybe this can
accomodate your needs and then you can force X to
re-read the config file which accomplish more or less
exactly what you want to do.
> system. Xfree has been getting closer to this.
> GGI can help go all
> the way.
>
> Xfree needs to start with the goal of getting rid
> of the
> configuration files and to "just make things
> work".
>
> I could go on, but I think I've expressed enough of
> my sentiment. The
> XFree project has the attention and mindshare of the
> free *nix
> community. In order to take *nix graphics to the
> next level, Xfree
> needs to change it's entire mindset. It's more
> important to shed this
> mindset allowing the end-user complexity of UNIX/X11
> than it is to
> shed the wire protocol. However, by welcoming and
> adopting GGI, Xfree
> can take *nix graphics to the next level, meeting
> and surpassing
> Windows graphics in many ways.
Maybe you need to change your mindset about the
greatness of windows graphics? Sure I would like a
bugfree X with better features, greater hardware
support and faster-than-m$windows 3d (but of course
with opengl instead of directx).
I am not interested in picking a fight so I appologise
if I upset anyone.
Best regards
Peter Karlsson
PS. Maybe, just maybe, the graphic hardware will look
_radically_ different in a few years from now...
>
> Food for thought... have at it.
>
> --
> David Jeske (N9LCA) + http://www.chat.net/~jeske/ +
> jeske@chat.net
> _______________________________________________
> Forum mailing list
> Forum@XFree86.Org
> http://XFree86.Org/mailman/listinfo/forum
_____________________________________________________
Gå före i kön och få din sajt värderad på nolltid med Yahoo! Express
Se mer på: http://se.docs.yahoo.com/info/express/help/index.html