help
Fabio Bellini
fabio at aris.com.br
Mon Mar 3 11:08:22 PST 2008
help
-----Mensagem original-----
De: xorg-bounces at lists.freedesktop.org
[mailto:xorg-bounces at lists.freedesktop.org] Em nome de
xorg-request at lists.freedesktop.org
Enviada em: segunda-feira, 3 de março de 2008 15:51
Para: xorg at lists.freedesktop.org
Assunto: xorg Digest, Vol 32, Issue 12
Send xorg mailing list submissions to
xorg at lists.freedesktop.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freedesktop.org/mailman/listinfo/xorg
or, via email, send a message with subject or body 'help' to
xorg-request at lists.freedesktop.org
You can reach the person managing the list at
xorg-owner at lists.freedesktop.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of xorg digest..."
Today's Topics:
1. Re: checking for library containing glXGetProcAddressARB...no
(Ian Romanick)
2. Re: Xephyr for multiterminal (Bill Crawford)
3. Re: GSoC CM collaboration (Kai-Uwe Behrmann)
4. Re: GSoC CM collaboration (Kai-Uwe Behrmann)
5. Re: GSoC CM collaboration (Olivier Galibert)
6. Re: GSoC CM collaboration (Kai-Uwe Behrmann)
7. Re: keyboard crashes in current git (David Miller)
8. Re: GSoC CM collaboration (Olivier Galibert)
9. Re: pciaccess clean up (Adam Jackson)
----------------------------------------------------------------------
Message: 1
Date: Mon, 03 Mar 2008 10:01:34 -0800
From: Ian Romanick <idr at us.ibm.com>
Subject: Re: checking for library containing glXGetProcAddressARB...no
To: xorg at lists.freedesktop.org
Message-ID: <47CC3CFE.6000605 at us.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Eran Maman wrote:
| I am trying to compile Xorg with mesa and I get this:
|
| checking for library containing glXGetProcAddressARB...no
| configure: error: cannot find GL library - make sure Mesa or other
| OpenGL pacakage is installed
|
| I installed mesa (make linux-dri; make install) successfully in
/usr/local/
| Does anyone know what else is missing?
I would guess that /usr/local/lib isn't in the default library search path.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFHzDz+X1gOwKyEAw8RAkj9AJ9WSX9cHUb79dQpe2ipO7qDGXonMQCfZ8wF
Ba1VBfgFevrZROIeCVFECRA=
=coOj
-----END PGP SIGNATURE-----
------------------------------
Message: 2
Date: Mon, 3 Mar 2008 18:03:44 +0000
From: "Bill Crawford" <billcrawford1970 at gmail.com>
Subject: Re: Xephyr for multiterminal
To: xorg at lists.freedesktop.org
Message-ID:
<544eb990803031003l6fef98c3y443468184348106b at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On 03/03/2008, Tiago Vignatti <vignatti at c3sl.ufpr.br> wrote:
> This is an odd situation because it can be considered as a
> feature-bloat. We already can do this only setting the DISPLAY
> environment, so we really want a -display option inside the server? I
> think not.
Almost all X applications accept a -display or --display option,
though. Admittedly this doesn't normally include the X *server*, but:
- [a] it's also an application running on top of X, and
- [b] Xnest includes a -display option.
A thought, nothing more ;o)
------------------------------
Message: 3
Date: Mon, 3 Mar 2008 19:08:45 +0100 (CET)
From: Kai-Uwe Behrmann <ku.b at gmx.de>
Subject: Re: GSoC CM collaboration
To: Olivier Galibert <galibert at pobox.com>
Cc: xorg at lists.freedesktop.org
Message-ID: <Pine.LNX.4.61.0803031854160.7085 at sirius.rasena>
Content-Type: TEXT/PLAIN; charset=US-ASCII
Am 03.03.08, 18:47 +0100 schrieb Olivier Galibert:
> On Mon, Mar 03, 2008 at 06:28:48PM +0100, Kai-Uwe Behrmann wrote:
> > This is a call to soften a concept. We talk here about where to create
the
> > colour transformation.
> > I am not against placing this code in the toolkit in the first place.
But
> > it seems more appealing to have the stuff in one place. This would be
> > where colour conversion happens - in the last pice of the colour chain.
> > My take is toolkits should be CM aware and let it passing through.
>
> Except for the cost. How many people just switch off composite
> managers because the cpu/gpu/power cost is high and what it gives in
> exchange is some eye candy not worth it. Especially when video comes
> into the picture. CM for normal users is almost on the same plane,
> eye candy. So it shouldn't carry a visible cost.
Ok I understand. You speak about efficiency. Tuning can happen in various
places.
But I feel we should start with a clear concept.
Once that runs, people, including toolkit developers, have something to
refere to. Optimisations in advance have the disadvantage, that it's
often difficult to estimate if they succeed.
> Running a pixel shader on everything you send to the screen is far
> from zero cost. Especially on laptops, which don't always have pixel
> shaders in the first place.
Yes, thats not so nice. But like with every architecture. There is a start
needed. As long as this initial colour managed desktop works almost as
proposed, despite the speed break down on some systems, there is something
to easily continue.
A desktop with various hooks in various toolkits, for the favour of some
unshure optimisation, will be terrible to manage later on. Thats my
expectation.
As a workaround, CM could be switched of for slow laptops as you already
mentioned for other gadgets.
kind regards
Kai-Uwe Behrmann
--
developing for colour management
www.behrmann.name + www.oyranos.org
------------------------------
Message: 4
Date: Mon, 3 Mar 2008 19:25:13 +0100 (CET)
From: Kai-Uwe Behrmann <ku.b at gmx.de>
Subject: Re: GSoC CM collaboration
To: Olivier Galibert <galibert at pobox.com>
Cc: xorg at lists.freedesktop.org, Nicolas Mailhot
<nicolas.mailhot at laposte.net>
Message-ID: <Pine.LNX.4.61.0803031911040.7085 at sirius.rasena>
Content-Type: text/plain; charset="utf-8"
Am 03.03.08, 18:56 +0100 schrieb Olivier Galibert:
> On Mon, Mar 03, 2008 at 06:18:59PM +0100, Nicolas Mailhot wrote:
> > Le Lun 3 mars 2008 18:01, Olivier Galibert a ?crit :
> > > Where "the application" can mean in large part "the graphics toolkit",
> > > as in gtk, qt or even cairo. So it's not necessarily that numerous.
> >
> > That would mean configuration hell.
>
> If there is something to configure at the application level you're
> doing it wrong.
Thats an ideal. We have specialised applications which request to take
over complete control. For instance the already mentioned device
color calibrators or advanced HDR displaying. As well many imaging
applications want to retain control over the output. They should be
enabled by the same CM logic as the composit manager.
> > Please don't go there. Most users
> > will want every GUI app colour-managed if possible, so I don't see any
> > win is pushing this in the toolkits now. This is a receipe for a
> > painful convergence process later on.
>
> The toolkits should be client of a CM library that's actually
> efficient and useful with sRGB (and doesn't mix color spaces, white
> temperature and other crap). Combine that with an extension that
> would allow you to tell X "this image I'm sending you is CMed for that
> monitor" and you could get a very good result with the GPU only used
> when it couldn't really be avoided.
This can easily be reached otherwise. A toolkit can pre render regions
starting with colour managed values and pass this to the server with opt
out for CM. This is not impossible. Still we should create a reference for
all in the first. When a toolkit, then plays with CM, it should be easier
to spot problems.
I am pretty shure some pitfalls are not very obvious. A reference will
have then its own value.
The biggest problem in the process are ambiguities.
kind regards
Kai-Uwe Behrmann
--
developing for colour management
www.behrmann.name + www.oyranos.org
------------------------------
Message: 5
Date: Mon, 3 Mar 2008 19:24:57 +0100
From: Olivier Galibert <galibert at pobox.com>
Subject: Re: GSoC CM collaboration
To: Kai-Uwe Behrmann <ku.b at gmx.de>
Cc: xorg at lists.freedesktop.org
Message-ID: <20080303182457.GE7333 at dspnet.fr.eu.org>
Content-Type: text/plain; charset=us-ascii
On Mon, Mar 03, 2008 at 07:08:45PM +0100, Kai-Uwe Behrmann wrote:
> Ok I understand. You speak about efficiency. Tuning can happen in various
> places.
>
> But I feel we should start with a clear concept.
>
> Once that runs, people, including toolkit developers, have something to
> refere to. Optimisations in advance have the disadvantage, that it's
> often difficult to estimate if they succeed.
Premature pessimization is the root of all evil. A concept that is
slow-by-design, as is running a pixel shader on everything sent to the
screen, and which will badly integrate in anything already using the
GPU for its own needs (like accelerated cairo) is just a broken
concept. Not a clear one.
> Yes, thats not so nice. But like with every architecture. There is a start
> needed. As long as this initial colour managed desktop works almost as
> proposed, despite the speed break down on some systems, there is something
> to easily continue.
That wouldn't be the first stillborn X project, that's for sure.
OG.
------------------------------
Message: 6
Date: Mon, 3 Mar 2008 19:33:48 +0100 (CET)
From: Kai-Uwe Behrmann <ku.b at gmx.de>
Subject: Re: GSoC CM collaboration
To: Tomas Carnecky <tom at dbservice.com>
Cc: xorg at lists.freedesktop.org
Message-ID: <Pine.LNX.4.61.0803031926320.7085 at sirius.rasena>
Content-Type: TEXT/PLAIN; charset=US-ASCII
Am 03.03.08, 18:59 +0100 schrieb Tomas Carnecky:
> Olivier Galibert wrote:
> > So the special atoms are attached to _root_ windows only, and not
> > windows in general. And they obviously don't specify the profiles for
> > only their own contents but for all the subwindows too. Makes more
> > sense.
>
> I was thinking more along these lines:
> - the root window specifies which profile the monitor uses
> - each window can specify in which profile its contents are
Unfortunedly this is not so clear. There will be windows which have
content up to the border and many which have differing regions. For
instance a paint application will have widgets in native space, while the
drawing area is tagged. The same for web browsers.
> Then someone deep down the chain, I'm proposing the compositing manager,
would
> go and perform the appropriate transformations between the profiles.
Agreed.
> It adds additional costs, that's true, but so does if every toolkit does
the
> transformation on its own! Also, you wouldn't have to run the shader on
every
> window, maybe only on those that have a profile specified on their window
and
> by that are showing that they care about the colors.
I'd expect the first implementation to be costly. Possibly there will
be enough time to implement some optimisations already.
kind regards
Kai-Uwe Behrmann
--
developing for colour management
www.behrmann.name + www.oyranos.org
------------------------------
Message: 7
Date: Mon, 03 Mar 2008 10:41:37 -0800 (PST)
From: David Miller <davem at davemloft.net>
Subject: Re: keyboard crashes in current git
To: daniel at fooishbar.org
Cc: xorg at lists.freedesktop.org
Message-ID: <20080303.104137.141239398.davem at davemloft.net>
Content-Type: Text/Plain; charset=us-ascii
From: Daniel Stone <daniel at fooishbar.org>
Date: Mon, 3 Mar 2008 10:37:53 +0200
> On Sun, Mar 02, 2008 at 10:31:09PM -0800, David Miller wrote:
> > I suspect it's caused by all of the recent XKB work by Daniel Stone.
> >
> > My keyboard is using pre-XKB keymaps, the curKeySyms.map is NULL for
> > the device so even the very first getevents call gets a SIGSEGV.
>
> While you have definitely encountered a bug, I'd definitely recommend
> using a real keymap, rather than having a broken setup whereby it falls
> back to defaults.
If you look at the InputDevice section I provided, I do. It's not
getting picked up for some reason.
When I traced the code all of the 'names' members are NULL when
XkbDDXLoadKeymapsByNames() is called by XkbInitKeyboardDeviceStruct.
Perhaps some bug got introduced into the config parser or some other
area of this xkb code.
> > Here is a trace from some of the relevant code:
> >
> > InitKeyboardDeviceStruct(dev[0x338bb8],pSyms[0xff9ad5b8])=1
> > InitKeyboardDeviceStruct: dev->key->curKeySyms.map[(nil)]
> >
> > So XKB is passing in the non-NULL pSyms but for some reason
> > it isn't getting attached to dev->key->curKeySyms.map
> >
> > GetKeyboardValuatorEvents: pDev(0x338bb8) map((nil))
> >
> > And then we crash in GetKeyboardValuatorEvents because it is
> > NULL.
>
> Please file a bug at http://bugs.freedesktop.org.
Sorry, I don't have time to do this.
I did however fully track down the cause of the problem and traced the
whole initialization of the keyboard map and showed why the code sets
it to NULL. And if you read the rest of my replies you'll see not
only that information, but the exact changeset of your's that
introduced the crash.
So hopefully you'll be motivated enough by that to fix the regression
you changes added. Although, in my opinion, the mere existence of a
known regression like this one should be sufficient for that.
BTW, even with this oops fixed there are lots of other keyboard
related problems resulting from your changes. For example, xterm's
"Alt/Numlock Modifiers" setting no longer has any effect.
------------------------------
Message: 8
Date: Mon, 3 Mar 2008 19:46:16 +0100
From: Olivier Galibert <galibert at pobox.com>
Subject: Re: GSoC CM collaboration
To: Tomas Carnecky <tom at dbservice.com>
Cc: graeme at argyllcms.com, xorg at lists.freedesktop.org
Message-ID: <20080303184616.GA16269 at dspnet.fr.eu.org>
Content-Type: text/plain; charset=us-ascii
On Mon, Mar 03, 2008 at 06:59:50PM +0100, Tomas Carnecky wrote:
> It adds additional costs, that's true, but so does if every toolkit does
> the transformation on its own!
*Way* less in the toolkit, though. Look at your screen, and think
about the number of color lookups the toolkit would have to do
compared to the number of pixels in the window.
> Also, you wouldn't have to run the shader
> on every window, maybe only on those that have a profile specified on
> their window and by that are showing that they care about the colors.
Well, if you want to do it on for the windows which care, your job is
already done. The applications which do care about CM already manage
it internally. No need to add anything else in the server or the
composite manager (which I've yet to see someone keep running after
the novelty has worn off).
OG.
------------------------------
Message: 9
Date: Mon, 03 Mar 2008 13:53:06 -0500
From: Adam Jackson <ajax at redhat.com>
Subject: Re: pciaccess clean up
To: Ian Romanick <idr at us.ibm.com>
Cc: xorg Mailing List <xorg at lists.freedesktop.org>
Message-ID: <1204570386.10971.6.camel at localhost.localdomain>
Content-Type: text/plain; charset="us-ascii"
On Mon, 2008-03-03 at 09:52 -0800, Ian Romanick wrote:
> This is by design. In the pre-PCI-rework discussions we decided that it
> was pure evil for the X server to muck about with PCI device / bus
> enables. I thought that the int10 boot-strap was still enabled, though.
Well, it has to go somewhere. In the ideal world I have kernel drivers
for everything and that handles enabling. Instead...
So until I get an ideal world, I'd like that the server enable my PCI
devices please. Because what we've got right now, where trying to post
a secondary card wedges the machine, is clearly crap.
- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url :
http://lists.freedesktop.org/archives/xorg/attachments/20080303/97e08683/att
achment.pgp
------------------------------
_______________________________________________
xorg mailing list
xorg at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
End of xorg Digest, Vol 32, Issue 12
************************************
More information about the xorg
mailing list