On Thu, Jan 22, 2004 at 05:12:28PM -0500, Michael Taylor wrote:
Marc Aurele La France wrote:
This came up while helping some clueless Windows exile(e):
So, how come Debian stable is still at XFree86 4.1?
Because that is what they had in 'testing' when they released Debian 3.0r0
(woody
://people.debian.org/~daenzer/dri-trunk ./
deb-src http://people.debian.org/~daenzer/dri-trunk ./
As backporting 4.3.0 to debian/woody needs that you already have a
running 4.2.1 backport and some other dependency hell.
Well, he has installed (and re-installed) from woody CDs. I've pointed
him
Sven Luther wrote:
On Thu, Jan 22, 2004 at 05:12:28PM -0500, Michael Taylor wrote:
I don't understand the Debian policy but it would be nice if at least 4.3.0 was
included in their release of sarge as stable next month.
A debian/sarge release next month would most assuredly be premature
On Fri, Jan 23, 2004 at 10:51:24AM -0500, Michael Taylor wrote:
Sven Luther wrote:
On Thu, Jan 22, 2004 at 05:12:28PM -0500, Michael Taylor wrote:
I don't understand the Debian policy but it would be nice if at least 4.3.0 was
included in their release of sarge as stable next month
This came up while helping some clueless Windows exile(e):
So, how come Debian stable is still at XFree86 4.1?
Marc.
+--+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network
Marc Aurele La France wrote:
This came up while helping some clueless Windows exile(e):
So, how come Debian stable is still at XFree86 4.1?
Because that is what they had in 'testing' when they released Debian 3.0r0
(woody) back in July 2002. Currently their 'testing' aka sarge has XFree86
On Thu, 22 Jan 2004, Michael Taylor wrote:
Marc Aurele La France wrote:
This came up while helping some clueless Windows exile(e):
So, how come Debian stable is still at XFree86 4.1?
Because that is what they had in 'testing' when they released Debian 3.0r0
(woody) back in July 2002
David Dawes wrote:
On Fri, Dec 12, 2003 at 09:57:39AM -0600, Warren Turkal wrote:
This changes the configuration, only for Debian, such that the manpages
end up in the right places with the right names. I would be wonderful if
this could be committed so this happens automatically for people
I was messing around with the Debian packages a that are in the 4.3.0 Debian
packages and trying to apply them to 4.3.901. I came across one that
applied that I thought was already done. Does DPMS on ati radeon work in
the 4.3.901? I could not find the bug in bugzilla that used to be
associated
This changes the configuration, only for Debian, such that the manpages end
up in the right places with the right names. I would be wonderful if this
could be committed so this happens automatically for people compiling on
Debian.
Also, is there any chance of that documentation patch I put
I was messing around with the Debian packages a that are in the 4.3.0 Debian
packages and trying to apply them to 4.3.901. I came across one that
applied that I thought was already done. Does DPMS on ati radeon work in
the 4.3.901? I could not find the bug in bugzilla that used to be
associated
This is a patch to add sun type6 keyboard support. It comed from the patches
debian puts on the 4.3.0 source before building the packages. I think this
type of info should be passed to the XFree86 core so that everyone who uses
XFree86 can take advantage of this.
Warren Turkal
--- xc/programs
On Fri, 2003-06-13 at 00:10, Alex Deucher wrote:
there are alot of issues with dualhead and LCDs on PPC. I believe the
fix is to use fbdev, but I'm not sure anyone has gotten dualhead to
work yet. check the archives from last month.
I had it working on the M6 a while ago, I haven't yet tried
Ben,
Thanks for the information. I used fbset -x and updated XF86Config-4
accordingly.
All of the test results from my original post were without using the
kernel fbdev driver. I just now went ahead and added Option UseFBDev
to the lcd-related device section in XF86Config-4 and set BusID to
On Fri, 2003-06-13 at 17:08, Andreakis, Dean (MED) wrote:
Given this result I tried comparing the sections of code in the kernel
fbdev driver and the XF86 radeon driver that sets up the PLL and there
was just a few minor diff's in the default min/max values. I went ahead
and changed these to
Alex,
I went ahead and commented out the dri section and the Load dri, Load
GLcore and Load glx lines in the Module section of XF86Config-4 to
try and prevent the DRI drivers from loading but I still see the same
messages in the XF86 log file. Maybe I need to do something else to stop
DRI from
It's not the DRI per se... it's the radeon memory manager. it attempts
to statically allocate offscreen memory for use by the DRI, pixmaps,
etc. It has no effect on modes, so you can safely ignore it.
Alex
--- Andreakis, Dean (MED) [EMAIL PROTECTED] wrote:
Alex,
I went ahead and commented
file. Maybe I need to do something else to stop
DRI from trying to load...
Don't worry about the DRI, it shouldn't have any influence on your
problem. It gets disabled with multihead anyway.
--
Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer
Software libre enthusiast
iBook that has
Debian(sid) installed and XFree86 4.3.0.
The iBook has an ATI Mobility Radeon 7500 (M7) installed. In order to
alleviate configuration issues I set the same mode up successfully on
my
Dell laptop with RH9 installed that also has the same ATI video chip
and
XFree86 4.3.0. I
I dont really know driver or chipset in detail,
but its the way that it needs programming so
that the timing for the LCD does match. black
or striped or whatever effects do indcate
wront timing for the flat pane display.
If the device is capable of dual head in other
OS condtions then it can do
20 matches
Mail list logo
