Mailing List Archive

On Sun, 2010-01-24 at 10:51 -0800, Mark Knecht wrote:
> Did xorgconfig go away?
>
http://www.gentoo.org/doc/en/xorg-config.xml gives a pretty up to date
status. You might want to go with the flow (dbus,hal,udev) vice swimming
upstream.

On Sun, Jan 24, 2010 at 11:06 AM, Drake Donahue <donahue95@comcast.net> wrote:
> On Sun, 2010-01-24 at 10:51 -0800, Mark Knecht wrote:
>> Did xorgconfig go away?
>>
> http://www.gentoo.org/doc/en/xorg-config.xml gives a pretty up to date
> status. You might want to go with the flow (dbus,hal,udev) vice swimming
> upstream.
>

Thanks. Yeah, I've just installed hal and started down that path but
it isn't work. With hal coming out of xorg-server in the near future I
was trying to see if I could just get X working by hand. I'm very,
very, very frustrated with this new motherboard right now. After days
the machine isn't usable and I'm running out of energy.

On 01/24/2010 09:15 PM, Mark Knecht wrote:
> On Sun, Jan 24, 2010 at 11:06 AM, Drake Donahue<donahue95@comcast.net> wrote:
>> On Sun, 2010-01-24 at 10:51 -0800, Mark Knecht wrote:
>>> Did xorgconfig go away?
>>>
>> http://www.gentoo.org/doc/en/xorg-config.xml gives a pretty up to date
>> status. You might want to go with the flow (dbus,hal,udev) vice swimming
>> upstream.
>>
>
> Thanks. Yeah, I've just installed hal and started down that path but
> it isn't work. With hal coming out of xorg-server in the near future I
> was trying to see if I could just get X working by hand. I'm very,
> very, very frustrated with this new motherboard right now. After days
> the machine isn't usable and I'm running out of energy.

What doesn't work exactly?

On Sun, Jan 24, 2010 at 11:18 AM, Nikos Chantziaras <realnc@arcor.de> wrote:
> On 01/24/2010 09:15 PM, Mark Knecht wrote:
>>
>> On Sun, Jan 24, 2010 at 11:06 AM, Drake Donahue<donahue95@comcast.net>
>>  wrote:
>>>
>>> On Sun, 2010-01-24 at 10:51 -0800, Mark Knecht wrote:
>>>>
>>>> Did xorgconfig go away?
>>>>
>>> http://www.gentoo.org/doc/en/xorg-config.xml gives a pretty up to date
>>> status. You might want to go with the flow (dbus,hal,udev) vice swimming
>>> upstream.
>>>
>>
>> Thanks. Yeah, I've just installed hal and started down that path but
>> it isn't work. With hal coming out of xorg-server in the near future I
>> was trying to see if I could just get X working by hand. I'm very,
>> very, very frustrated with this new motherboard right now. After days
>> the machine isn't usable and I'm running out of energy.
>
> What doesn't work exactly?

I apologize at the outset. I'm ranting. I know it. I'm sorry in
advance. Please everyone, please accept my apologies.

Unable to run any sort of X so far. I've tried make.conf two ways and
then maybe 50 recompiles of the kernel with different things on and
off.

VIDEO_CARDS="intel vesa fbdev"
VIDEO_CARDS="intelvesa"

In the first method when I boot if I have KMS_HELPERS enabled in the
kernel then the screen goes black at the udev step during boot and I
have to ssh in to reboot the machine. I can stop that by adding
i915.modeset=0 to the boot command line. However when I try to start X
it complains about a bunch of things, but the first one is that there
are no monitors attached to the VGA ports. The VGA in this thing is
part of the Intel chipset, it's a new chipset, and from the
Intel-graphics email list it sort of sounds like I'm one of the first
folks to pop up using it for Linux outside of maybe some core group at
Intel. I don't know and please excuse my frustration.

I tried get-edid | parse-edid and the monitors are there so I don't
know why they shouldn't be recognized.

I've just tried turning on hal and am trying to figure out how to make
the system do vesa instead of native Intel. However this is the
problem with hal and stupid people like me. It doesn't give me a
choice. If I had xorgconfig I had hoped I could just choose it and
make a xorg.conf file but no such luck.

I've tried lots of other things. On the vesa front right now it's
complaining it cannot find an i810 driver when before it was trying to
use an i915 driver. Maybe it uses different drivers for different
types of X setups?

- Mark

On 01/24/2010 09:34 PM, Mark Knecht wrote:
> [...]
> I apologize at the outset. I'm ranting. I know it. I'm sorry in
> advance. Please everyone, please accept my apologies.

It's OK, we've all been there ;)


> Unable to run any sort of X so far. I've tried make.conf two ways and
> then maybe 50 recompiles of the kernel with different things on and
> off.
>
> VIDEO_CARDS="intel vesa fbdev"
> VIDEO_CARDS="intelvesa"

"intelvesa" doesn't exist. Basically, do a:

equery uses xorg-drivers

to see what values are acceptable for VIDEO_CARDS. The
"video_cards_intel" USE flag for example means it's expanded from
VIDEO_CARDS="intel"


> In the first method when I boot if I have KMS_HELPERS enabled in the
> kernel then the screen goes black at the udev step during boot and I
> have to ssh in to reboot the machine. I can stop that by adding
> i915.modeset=0 to the boot command line.

When using KMS, make sure you have vesafb (or any other framebuffer
driver) disabled.

The next step is probably searching and asking for advice in the Intel
section of Phoronix:

http://www.phoronix.com/forums/forumdisplay.php?f=44

Also, with new chipsets, it's pretty much a *must* to run the latest
versions of X and kernel. At the moment that means xorg-server-1.7.4
and gentoo-sources-2.6.32-r2. If you're on Gentoo stable you will need
a lot of unmasking :P

On Sun, Jan 24, 2010 at 11:46 AM, Nikos Chantziaras <realnc@arcor.de> wrote:
<SNIP>
>>
>> VIDEO_CARDS="intel vesa fbdev"
>> VIDEO_CARDS="intelvesa"

That was a mistake typing. Should have been "intel vesa" as the guy on
the intel-gfx list suggest I try vesa and right now I cannot seem to
get an i810 driver which is what just typing 'X' complains about.

>
> "intelvesa" doesn't exist.  Basically, do a:
>
>  equery uses xorg-drivers
>
> to see what values are acceptable for VIDEO_CARDS.  The "video_cards_intel"
> USE flag for example means it's expanded from VIDEO_CARDS="intel"
>
>
>> In the first method when I boot if I have KMS_HELPERS enabled in the
>> kernel then the screen goes black at the udev step during boot and I
>> have to ssh in to reboot the machine. I can stop that by adding
>> i915.modeset=0 to the boot command line.
>
> When using KMS, make sure you have vesafb (or any other framebuffer driver)
> disabled.
>
> The next step is probably searching and asking for advice in the Intel
> section of Phoronix:
>
>  http://www.phoronix.com/forums/forumdisplay.php?f=44
>
> Also, with new chipsets, it's pretty much a *must* to run the latest
> versions of X and kernel.  At the moment that means xorg-server-1.7.4 and
> gentoo-sources-2.6.32-r2.  If you're on Gentoo stable you will need a lot of
> unmasking :P

I have no problem I guess with ~amd64 if that's what I need to do but
the Intel guy said all I needed was xf86-intel-video 2.9 or higher and
I've got 2.9.1. He didn't suggest I needed xorg-server-1.7. I am
running gentoo-sources-2.6.32-r2.

Once I go ~amd64 I cannot go back right? Basically someday I could do
a reinstall but other than that I just have to stay ~amd64?

I'm not against doing it because desperately need the machine. If it
doesn't help it doesn't matter because right now what I have isn't
worth applying electricity to me.

The issue here is that Intel took a path of putting XP drivers out
there but there's no real support for how to make the machine run XP
which I need for TradeStation or I cannot trade futures. I've been
unable to trade for about 8 trading days now. If I cannot get XP on
the machine then the way I see it is run X and see if VMware can do
the job, or else spend $300 for some new version of Windows which I
HATE to think of doing, and I don't have it anyway. (Well, I do, but
money is REALLY tight.)

How do I go totally testing? Is that ARCH=~amd64 in my make.conf? Do I
really want that? Every leading edge version of every package on my
system? gcc? glibc? Isn't that risky when you need a machine to work
every day?

Thanks,
Mark

On Sun, Jan 24, 2010 at 12:12 PM, Mark Knecht <markknecht@gmail.com> wrote:
<SNIP>
> How do I go totally testing? Is that ARCH=~amd64 in my make.conf? Do I
> really want that? Every leading edge version of every package on my
> system? gcc? glibc? Isn't that risky when you need a machine to work
> every day?
>

ACCEPT_KEYWORDS="~amd64"

but I REALLY don't want to do that with Gnome or xfce - stuff like
that. I suppose this means I have to unmask everything by hand package
by package which is a pain...

- Mark