[vbox-dev] What's up with 4.3.8 and VBOX_USE_SYSTEM_XORG_HEADERS=1

[Michael Thayer]

Hello Sérgio,

I will "top-post" here, as I can no longer follow the thread below.  A 
bit of investigation around our 3D driver for Linux guests shows the 
following.  The code should still work against the very latest versions 
of Mesa.  The reason that the headers in the X server source that you 
were using to build it without our bundled headers have disappeared is 
because the X server was also bundling them (in a rewritten form), much 
the same way as we are, and they have done a significant re-write of 
their GLX code (I haven't yet investigated what you reported about them 
having moved in the X server code).  The interfaces are still present in 
Mesa, where they originally come from.  I do still plan to clean up 
there in quite a major way, but I really can't say when.  The list of 
"more important" things I have to do remains roughly constant, with new 
ones appearing about as fast as I can finish older ones.

I also found that 3D is still working on Fedora 20, and I expect it to 
be working on Fedora 21 too, though I haven't yet had time to verify 
that.  So that is probably not the reason for the slowdown reported by 
Quickbooks.  A colleague is planning to investigate that if/when there 
is time.

Regards,

Michael

On 25/03/14 01:43, Sérgio Basto wrote:
> On Qui, 2014-03-20 at 23:16 +0000, Sérgio Basto wrote:
>> On Qui, 2014-03-20 at 11:53 +0100, Michael Thayer wrote:
>>> Hello Sérgio,
>>>
>>> On 18/03/14 17:48, Sérgio Basto wrote:
>>>>> On 18/03/14 06:41, Sérgio Basto wrote:
>>>>> [...]
>>>>>> Many thanks for your reply, OK , hopefully we are talking about drivers
>>>>>> for guest system , so is not much used, though that PatchMesaGLAPITable
>>>>>> was sort of a fix ...
>>>>> [...]
>>>>> If you are not interested in guest drivers you might just build with
>>>>> "VBOX_WITHOUT_ADDITIONS=1" set and then remove any Additions code you do
>>>>> not want in your sources, as it should not get built at all.
>>>>
>>>> No, we in rpmfusion do "our" guest package for Fedora, I use it to test
>>>> devel versions of Fedora mainly and also use it for legacy versions, so
>>>> I want build guest Additions for Fedora without bundle sources, mainly.
>>>>
>>>>> Was the
>>>>> patch you attached to your last message a reworked version of the
>>>>> previous one?
>>>>
>>>> yes is a rework , for Xserver 1.14
>>>>
>>>>>    I only looked at it briefly, but it did look like an
>>>>> improvement, so I will try to look at it more closely when I get the chance.
>>>
>>> I took a closer look at your patch (I am not absolutely familiar with
>>> the workings of that "driver") and I'm afraid it isn't really something
>>> I can apply.  The driver is using X.Org/Mesa internals, which is why it
>>> needs either bundled internal headers or the actual X server source.
>>
>> OK, as I point out, only PatchMesaGLAPITable function use X.Org/Mesa
>> internals.
>
>
>
>>> Though I haven't yet tested, what you said about it not building on
>>> Fedora 21 looks like a genuine problem, see also Quickbooks's e-mail to
>>> the list.  I will investigate that.
>
> Hi, I was puzzled with disappear of glapi.h, but glapi.h not disappeared
> it just "moved", not quite, is a long story that I cant explain in
> English .
> glx have been spit in indirect rendering and that part still in X11
> source and direct rendering that is definitely in mesa3d sources. Mesa3d
> have the glapi [1] in his source.
> Now I'm investigation, why Mesa package of Fedora doesn't expose headers
> of glapi. I found this when I saw a packaged called mesa-libglapi which
> is part of Mesa src.rpm , maybe to avoid duplicated headers in Fedora
> 20 ...
>
> Hope that can help in something .
>
>
> [1] http://www.mesa3d.org/sourcetree.html
>
>
>
>


-- 
ORACLE Deutschland B.V. & Co. KG   Michael Thayer
Werkstrasse 24                     VirtualBox engineering
71384 Weinstadt, Germany           mailto:michael.thayer at oracle.com

Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Geschäftsführer: Jürgen Kunz

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher