headers
Greg A. Woods | 5 Aug 2006 22:44
X-Face
Favicon

Re: definition of xf86LoadVBEModule() macro missing from xfree/xc/programs/Xserver/hw/xfree86/vbe/vbe.h?

At Sun, 30 Jul 2006 12:04:51 +0200,
Julio M. Merino Vidal wrote:
> 
> You are right in that there is a problem, but there is no build error
> (hence why it went unnoticed for so long).  The problem only appears
> at run time with a warning message that I had not noticed until now:
> 
> Symbol xf86LoadVBEModule from module
> /usr/X11R6/lib/modules/drivers/nv_drv.o is unresolved!

Well the build does fail immediately if one links with -static.  ;-)

That's one, albiet relatively minor, reason why I do like to link
everything statically for my systems.

Until the dynamic linker is fixed to have an option to force it to fail
if any symbol remains undefined (or there are other potential load-time
problems, such as multiple definitions, etc.) then I think it would be
very wise for someone other than myself (perhaps even the automated
builds) to do at least one complete static-linked build for at least
some architectures.

> The fix is trivial: just revert the offending line to what it was (a
> call to xf86LoadSubModule).  I'm now testing the fix locally
> (attached).

Thanks very much!  All seems OK with static xsrc-current builds on 1.6.x
now (though I don't think I have any hardware to test if the module
acutally works).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Lorenz | 7 Aug 2006 21:36
Picon

xorg - help needed


Hello,

now the bits and pieces necessary to build at least the xorg 7.0 
Xserver and a bunch of drivers are in place, I added the missing bits 
and pieces to make it work on sparc64, sparc and macppc. Our additions 
to wsfb and suncg6 are still missing but they're easy to do.
Anyway, I think it's time to start getting it into NetBSD's build 
process - something I don't have much of a clue about. I also have no 
idea if there's anything missing for i386/amd64 - I don't have either 
hardware.

have fun
Michael
Permalink | Reply | 7 comments |
headers
Martin Husemann | 7 Aug 2006 22:54
Picon

Re: xorg - help needed

On Mon, Aug 07, 2006 at 03:36:29PM -0400, Michael Lorenz wrote:
> Anyway, I think it's time to start getting it into NetBSD's build 
> process - something I don't have much of a clue about.

It is pretty easy to do, albeit boring work. You need a build log of the
native build for each arch that you convert, but I think it only makes sense
for volunteers to work on it after we decided how to proceed in general and
did a working conversion for one arch.

> I also have no 
> idea if there's anything missing for i386/amd64 - I don't have either 
> hardware.

I have both but couldn't get my amd64 X working yet - maybe xorg is a good
chance for that ;-)

The question is how to do this, from a repository point of view. We could
create a macallan-xorg branch that covers src/x11 - or we could could
force things and just start converting src/x11 to xorg (i.e. break it for
all unconverted archs) after the 4.0 branch has been created. The political
correct way, of course, is the former, but I wouldn't mind doing the latter.

I volunteer to help doing the conversion at least for some archs that I
can test (sparc64, i386, amd64 - if amd64 X works with X.org for me), and
I suggest that we start with a known working one, i.e. sparc64.

If we get this done and tested for all supported archs, it would make a
great pullup to 4.0, IMHO.

Martin
(Continue reading)

Permalink | Reply | 4 comments |
headers
Pavel Cahyna | 7 Aug 2006 23:04
Picon

Re: xorg - help needed

On Mon, Aug 07, 2006 at 03:36:29PM -0400, Michael Lorenz wrote:
> Hello,
> 
> now the bits and pieces necessary to build at least the xorg 7.0 Xserver and a 
> bunch of drivers are in place, I added the missing bits and pieces to make it 
> work on sparc64, sparc and macppc. Our additions to wsfb and suncg6 are still 
> missing but they're easy to do.
> Anyway, I think it's time to start getting it into NetBSD's build process - 
> something I don't have much of a clue about. I also have no idea if there's 
> anything missing for i386/amd64 - I don't have either hardware.

What about alpha?

Pavel
Permalink | Reply | 1 comment |
headers
Jeremy C. Reed | 7 Aug 2006 23:15

Re: xorg - help needed

How do you plan to keep the Xorg code in NetBSD updated? Or how are you 
going to get the Xorg's code (for later updates)?

I don't recall any single or even few tarballs for (recent) Xorg X11. And 
even the latest release download site was incomplete. CVS is not used. And 
the code is in different GIT repos. Xorg is made up of maybe more than 100 
different components (which are provided as tarballs too).

Not a major issue as it can be solved technically.

But I guess it comes down to: is it worth doing this in NetBSD xsrc and 
also in pkgsrc?

By moving away from xsrc we will stop the X11 work that never got 
integrated upstream. Hopefully though this will encourage upstream patches 
and development instead of no development.

(As for wsfb, the Xorg wsfb developer indicated that he is looking at 
NetBSD's improvements for this.)
Permalink | Reply | 2 comments |
headers
Valeriy E. Ushakov | 7 Aug 2006 23:25
Picon

Re: xorg - help needed

On Mon, Aug 07, 2006 at 22:54:23 +0200, Martin Husemann wrote:

> On Mon, Aug 07, 2006 at 03:36:29PM -0400, Michael Lorenz wrote:
> > Anyway, I think it's time to start getting it into NetBSD's build 
> > process - something I don't have much of a clue about.
[...]
> The question is how to do this, from a repository point of view.  We
> could create a macallan-xorg branch that covers src/x11 - or we
> could could force things and just start converting src/x11 to xorg
> (i.e. break it for all unconverted archs) after the 4.0 branch has
> been created. The political correct way, of course, is the former,
> but I wouldn't mind doing the latter.
[...]
> If we get this done and tested for all supported archs, it would make a
> great pullup to 4.0, IMHO.

We have xsrc/xfree and xsrc/xorg under xsrc.

Why don't we have src/x11 (for xfree) and src/xorg (for xorg) to match
that layout and provide smooth transition path, which is also easier
and less intrusive to pull up?

SY, Uwe
--

-- 
uwe <at> ptc.spbu.ru                         |       Zu Grunde kommen
http://snark.ptc.spbu.ru/~uwe/          |       Ist zu Grunde gehen
Permalink | Reply | 0 comments |
headers
Martin Husemann | 7 Aug 2006 23:38
Picon

Re: xorg - help needed

On Mon, Aug 07, 2006 at 04:15:57PM -0500, Jeremy C. Reed wrote:
> But I guess it comes down to: is it worth doing this in NetBSD xsrc and 
> also in pkgsrc?

Quite simple: we need to do this in xsrc and the crossbuild framework
or stop providing X binaries with releases. Ask old releng members
for the pain X caused before we were able to do it this way.

And I bet you are going to insist on a pkgsrc variant ;-)

Martin
Permalink | Reply | 0 comments |
headers
Michael Lorenz | 8 Aug 2006 01:21
Picon

Re: xorg - help needed


Hello,

On Aug 7, 2006, at 17:04, Pavel Cahyna wrote:

> On Mon, Aug 07, 2006 at 03:36:29PM -0400, Michael Lorenz wrote:
>> Hello,
>>
>> now the bits and pieces necessary to build at least the xorg 7.0 
>> Xserver and a
>> bunch of drivers are in place, I added the missing bits and pieces to 
>> make it
>> work on sparc64, sparc and macppc. Our additions to wsfb and suncg6 
>> are still
>> missing but they're easy to do.
>> Anyway, I think it's time to start getting it into NetBSD's build 
>> process -
>> something I don't have much of a clue about. I also have no idea if 
>> there's
>> anything missing for i386/amd64 - I don't have either hardware.
>
> What about alpha?

ENOHARDWARE

I have access to sparc, sparc64 and macppc machines, that's it. So I 
don't know about alpha either.

have fun
Michael
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael | 8 Aug 2006 01:28
Picon
Gravatar

Re: xorg - help needed


Hello,

On Aug 7, 2006, at 17:15, Jeremy C. Reed wrote:

> How do you plan to keep the Xorg code in NetBSD updated? Or how are you
> going to get the Xorg's code (for later updates)?

What we have now is xorg 7.0 pulled from their cvs repository and a few 
critical patches applied. I don't see why we couldn't continue like 
that, just pulling the next release from git.

> I don't recall any single or even few tarballs for (recent) Xorg X11. 
> And
> even the latest release download site was incomplete. CVS is not used. 
> And
> the code is in different GIT repos. Xorg is made up of maybe more than 
> 100
> different components (which are provided as tarballs too).

I didn't look at their repositories for some time now, was more 
concerned with getting to work what we have right now.

> But I guess it comes down to: is it worth doing this in NetBSD xsrc and
> also in pkgsrc?

Good question. Do the xorg packages from pkgsrc work on anything 
non-x86?
One point of having xorg in xsrc is cross-compiling.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Billington | 8 Aug 2006 10:54

NetBSD-3 support for i915GM- hang on boot

I found a message from Michael Erikson in NetBSD Tech-X11 list dated last December with patches to NetBSD
for 
enabling support for the Intel 915G/GM IGD.

I recently bought a new laptop that has one of these chipsets, and can report 
the following problem:

Model is a Uniwill E30I10 with WXGA 1280x768 display, http://www.uniwill.com/products/other/m30ei0/m30ei0_print.php

NetBSD3.0 GENERIC (before the patch): boots, Intel devices 0x2592/2792 not recognised, 
X11 can't have XV or hardware cursor (or read the VESA resolutions 
correctly). It always comes up with 1024x768 and not accelerated. There is no 
agpgart so the VESA driver has to be used. 

NetBSD-3 STABLE: (CVS 6 Aug 06) hangs on boot with Generic, Generic_Laptop and 
custom kernels. I updated the system using the procedure at
http://www.s-mackie.demon.co.uk/unix-notes/NetBSD-Updates.html 

The Intel chips (HB, IGD, IGD companion) are recognised, but the system hangs 
so early in boot there is little I can do to diagnose it.
I did try both with and without agp enabled, and with and without 
ACPI/PNPBIOS, with the same result.

From a remaining fragment of Dmesg with GENERIC_LAPTOP, the last line in the 
Dmesg is 
agp0: unknown memory configuration, disabling

So it looks like the 'stolen memory' code in agp_i810.c is failing to read the memory config and the agp is disabled.

I don't know if this is relevant, but in the source there is the comment that
(Continue reading)

Permalink | Reply | 4 comments |

Gmane