On Tue, 2005-03-15 at 08:01 +0200, Ville Syrjälä wrote:
> If radeonfb will allocate the buffer for the second head from the top of
> the memory users would basically have to guess it's location. matroxfb
> simply cuts the memory in two pieces and allocates the buffers from the
> start of each p
On Tue, 2005-03-15 at 00:30 -0500, Jon Smirl wrote:
> I agree that X has to be fixed to work cooperatively in this environment.
> The alternative is to just leave X alone and make all of this work for XGL.
> The user would then choose which environment they want to run.
>
> I'm leaning toward ju
On Mon, 2005-03-14 at 23:59 -0500, Michel Dänzer wrote:
> On Tue, 2005-03-15 at 09:37 +1100, Benjamin Herrenschmidt wrote:
> > > Be that as it may, it remains a fact that such a change would break
> > > existing installations...
> > >
> > > I think that mode setting and memory allocation should be
On Mon, Mar 14, 2005 at 11:59:37PM -0500, Michel Dänzer wrote:
> On Tue, 2005-03-15 at 09:37 +1100, Benjamin Herrenschmidt wrote:
> > > Be that as it may, it remains a fact that such a change would break
> > > existing installations...
> > >
> > > I think that mode setting and memory allocation sh
On Tue, 15 Mar 2005 09:37:53 +1100, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
>
> > Be that as it may, it remains a fact that such a change would break
> > existing installations...
> >
> > I think that mode setting and memory allocation should be separated. X
> > will always reserve enoug
On Mon, 14 Mar 2005 23:59:37 -0500, Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-03-15 at 09:37 +1100, Benjamin Herrenschmidt wrote:
> > > Be that as it may, it remains a fact that such a change would break
> > > existing installations...
> > >
> > > I think that mode setting and memory
On Tue, 2005-03-15 at 09:37 +1100, Benjamin Herrenschmidt wrote:
> > Be that as it may, it remains a fact that such a change would break
> > existing installations...
> >
> > I think that mode setting and memory allocation should be separated. X
> > will always reserve enough video RAM for the lar
On Mon, 14 Mar 2005, Adam K Kirchhoff wrote:
Michel DÃnzer wrote:
On Mon, 2005-03-14 at 18:05 -0500, Vladimir Dergachev wrote:
I am unsure of how to fix it though, as the call *is* needed, we should
not be reading from registers with engine busy.
Something may be needed, but probably not a wait
[[[
I am also cross posting to xorg mailing list.
The e-mail below discusses a RADEONWaitForIdleMMIO() call I put in
radeon_mergedfb.c before OUTREGP() calls in cursor functions.
The call was needed as OUTREGP() calls INREG() implicitly.
However, it turns out that this call breaks on SMP systems
Felix Kühling wrote:
Hi all,
I just uploaded a new DRIconf version (0.2.3), which features better
support for floating-point ranges like the brilinear option proposed
by Roland Scheidegger. There are also a few bug fixes and usability
improvements as well as updates and additions to the README fi
Michel DÃnzer wrote:
On Mon, 2005-03-14 at 18:05 -0500, Vladimir Dergachev wrote:
I am unsure of how to fix it though, as the call *is* needed, we should
not be reading from registers with engine busy.
Something may be needed, but probably not a wait for idle (which may
never succeed on an
On Tue, 2005-03-15 at 10:53 +1100, Benjamin Herrenschmidt wrote:
[snip]
> You are using radeonfb ? if yes, try without and let me know.
>
Just using the basic vga console.
> Ben.
Andrew
---
SF email is sponsored by - The IT Product Guid
(resend)
Fix sparse NULL/0 warning:
drivers/char/drm/radeon_state.c:1845:15: warning: Using plain integer as NULL
pointer
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
diffstat:=
drivers/char/drm/radeon_state.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -Naurp ./drivers/
On Mon, 2005-03-14 at 18:05 -0500, Vladimir Dergachev wrote:
>
> I am unsure of how to fix it though, as the call *is* needed, we should
> not be reading from registers with engine busy.
Something may be needed, but probably not a wait for idle (which may
never succeed on an SMP system). Other t
Michel DÃnzer wrote:
I also made it set the source pitch based on the image width. If the
image width is less than 64, we have a problem if the image height is
more than 1 (if the height is 1 the pitch doesn't matter). I made it
return an EINVAL error in that case. I didn't see that case ever
oc
On Mon, 2005-03-14 at 20:49 +, Andrew Clayton wrote:
> On Mon, 2005-03-14 at 15:32 +1100, Paul Mackerras wrote:
>
> > Have you tried the most recent kernel? There were some changes to the
> > AGP code that caused it to oops for me. Linus took my patch to fix
> > that this last weekend.
> >
Vladimir Dergachev wrote:
On Mon, 14 Mar 2005, Michel [ISO-8859-1] Dïnzer wrote:
On Mon, 2005-03-14 at 11:45 -0500, Adam K Kirchhoff wrote:
Michel DÃnzer wrote:
On Mon, 2005-03-14 at 07:34 -0500, Adam K Kirchhoff wrote:
glxgears usually runs fine till I move the mouse... The mouse will
stutter.
On Mon, 14 Mar 2005, Michel [ISO-8859-1] Dänzer wrote:
On Mon, 2005-03-14 at 11:45 -0500, Adam K Kirchhoff wrote:
Michel DÃnzer wrote:
On Mon, 2005-03-14 at 07:34 -0500, Adam K Kirchhoff wrote:
glxgears usually runs fine till I move the mouse... The mouse will
stutter.
I suspect this is caused by
> Be that as it may, it remains a fact that such a change would break
> existing installations...
>
> I think that mode setting and memory allocation should be separated. X
> will always reserve enough video RAM for the largest resolution it uses
> for the screen contents.
But X has no control o
On Tue, 2005-03-15 at 08:52 +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2005-03-14 at 11:20 -0500, Michel DÃnzer wrote:
> > On Mon, 2005-03-14 at 18:12 +1100, Benjamin Herrenschmidt wrote:
> > > On Sun, 2005-03-13 at 23:28 -0500, Michel DÃnzer wrote:
> > > > On Sun, 2005-03-13 at 17:43 +1100, Be
On Mon, 2005-03-14 at 17:30 +0100, Soeren Sandmann wrote:
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
>
> > In an ideal world ... However, since we are planning to move the memory
> > manager to the kernel, that would mean a kernel access (syscall, ioctl,
> > whatever...) twice per access
On Mon, 2005-03-14 at 11:20 -0500, Michel Dänzer wrote:
> On Mon, 2005-03-14 at 18:12 +1100, Benjamin Herrenschmidt wrote:
> > On Sun, 2005-03-13 at 23:28 -0500, Michel Dänzer wrote:
> > > On Sun, 2005-03-13 at 17:43 +1100, Benjamin Herrenschmidt wrote:
> > > >
> > > > And finally, I want to blank
>
> Ok so the problem is byte swapping. Looking at atyfb for example it uses
> the "big-endian" aperture on big-endian systems and selects the byte
> swapping method according to the bit depth. If that really means that all
> host access to the aperture gets byte swapped then I don't see how t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ville Syrjälä wrote:
> Makes me wish I had a PPC box alongside the x86 one.
You might like to try http://pearpc.sourceforge.net/.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFCNgGnXVaO67S1rtsRAuQ+AKCSkimy2poypyjls7ihX2bgtU6C
On Mon, 2005-03-14 at 15:32 +1100, Paul Mackerras wrote:
> Have you tried the most recent kernel? There were some changes to the
> AGP code that caused it to oops for me. Linus took my patch to fix
> that this last weekend.
>
2.6.11-bk10 is a slight improvement.
When X starts the screen goes
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=2702
--- Additional Comments From [EMAIL PROTECTED] 2005-03-14 12:28 ---
(In r
http://bugme.osdl.org/show_bug.cgi?id=4337
Summary: ATI Rage 128: messed up X
Kernel Version: from at least 2.6.11-bk8 to bk10
Status: NEW
Severity: high
Owner: [EMAIL PROTECTED]
Submitter: [EMAIL PROTECTED]
Distribution: Debian Sarge (t
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=2702
--- Additional Comments From [EMAIL PROTECTED] 2005-03-14 09:42 ---
(In r
Michel DÃnzer wrote:
On Mon, 2005-03-14 at 11:45 -0500, Adam K Kirchhoff wrote:
Michel DÃnzer wrote:
On Mon, 2005-03-14 at 07:34 -0500, Adam K Kirchhoff wrote:
glxgears usually runs fine till I move the mouse... The mouse will
stutter.
I suspect this is caused by the RADEO
On Mon, 2005-03-14 at 11:45 -0500, Adam K Kirchhoff wrote:
> Michel DÃnzer wrote:
>
> >On Mon, 2005-03-14 at 07:34 -0500, Adam K Kirchhoff wrote:
> >
> >>glxgears usually runs fine till I move the mouse... The mouse will
> >>stutter.
> >
> >I suspect this is caused by the RADEONWaitForIdleMMIO
Michel DÃnzer wrote:
On Mon, 2005-03-14 at 07:34 -0500, Adam K Kirchhoff wrote:
glxgears usually runs fine till I move the mouse... The mouse will
stutter.
I suspect this is caused by the RADEONWaitForIdleMMIO() call Vladimir
added to RADEONChooseCursorCRTC() on February 18th. I think thi
On Mon, Mar 14, 2005 at 05:30:04PM +0100, Soeren Sandmann wrote:
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
>
> > In an ideal world ... However, since we are planning to move the memory
> > manager to the kernel, that would mean a kernel access (syscall, ioctl,
> > whatever...) twice per
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
> In an ideal world ... However, since we are planning to move the memory
> manager to the kernel, that would mean a kernel access (syscall, ioctl,
> whatever...) twice per access to AGP memory. Not realistic.
Could the user space driver batch ma
On Mon, 2005-03-14 at 18:12 +1100, Benjamin Herrenschmidt wrote:
> On Sun, 2005-03-13 at 23:28 -0500, Michel DÃnzer wrote:
> > On Sun, 2005-03-13 at 17:43 +1100, Benjamin Herrenschmidt wrote:
> > >
> > > And finally, I want to blank the screen (using the accel engine) before
> > > setting the new
On Mon, 2005-03-14 at 07:34 -0500, Adam K Kirchhoff wrote:
>
> glxgears usually runs fine till I move the mouse... The mouse will
> stutter.
I suspect this is caused by the RADEONWaitForIdleMMIO() call Vladimir
added to RADEONChooseCursorCRTC() on February 18th. I think this
function will be ca
On Mon, 2005-03-14 at 15:32 +1100, Paul Mackerras wrote:
> Andrew Clayton writes:
>
> > 2.6.11-bk2 OK
> > 2.6.11-bk3 Lockup
>
> Have you tried the most recent kernel? There were some changes to the
It was still broken with -bk9.
> AGP code that caused it to oops for me. Linus took my patch to
On Sun, Mar 13, 2005 at 11:04:59PM +1100, Benjamin Herrenschmidt wrote:
> >
> > I must be missing something something obvious because I don't quite
> > understand what major drawbacks there are with the non-overlapping mode.
> > As I see it you get at least the same amount of CPU accessible memo
Vladimir Dergachev wrote:
On Mon, 14 Mar 2005, Adam K Kirchhoff wrote:
Vladimir Dergachev wrote:
Alright... So drm from both February 14th and January 1st are
locking up as well... Which is odd since I never had any of these
problem till this weekend. I'll start rolling back changes to the
On Mon, 14 Mar 2005, Adam K Kirchhoff wrote:
Vladimir Dergachev wrote:
Alright... So drm from both February 14th and January 1st are locking up
as well... Which is odd since I never had any of these problem till this
weekend. I'll start rolling back changes to the Mesa dri driver...
Perhaps
Vladimir Dergachev wrote:
Alright... So drm from both February 14th and January 1st are
locking up as well... Which is odd since I never had any of these
problem till this weekend. I'll start rolling back changes to the
Mesa dri driver... Perhaps this isn't directly related to the drm.
Oh,
On Sunday 13 March 2005 23:46, Adam K Kirchhoff wrote:
> Adam K Kirchhoff wrote:
> > I really am confused. This was all working (with my 9200) prior to
> > reinstalling Debian on my system on Friday. Thankfully it still works
> > (with drm 1.15.0) on my FreeBSD installation. Not really sure if
On Sun, 13 Mar 2005, Adam K Kirchhoff wrote:
While it's possible, it seems unlikely. I did recently upgrade from 2.6.10
to 2.6.11 (about a week before reinstalling Debian)... However, my lockups
only ever happen with running a 3D client, not just X.
*However,* I've been playing with different
42 matches
Mail list logo
