> Hello, Clint. Do you know anything else about this subject? You did a
> lot of development, any success?
I still don't have it working on the initial X startup.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
El Miércoles, 8 de Diciembre de 2004 06:47, Branden Robinson escribió:
> On Tue, Nov 16, 2004 at 05:44:30PM -0500, Clint Adams wrote:
> > > Okay. I've removed application of this patch from the TODO list; take
> > > all the time you need to work on this, and thanks a lot for go after it
> > > with
On Tue, Nov 16, 2004 at 05:44:30PM -0500, Clint Adams wrote:
> > Okay. I've removed application of this patch from the TODO list; take
> > all the time you need to work on this, and thanks a lot for go after it
> > with vigor.
>
> Slow progress.
>
> Here is a diff of the registers I know about o
> Okay. I've removed application of this patch from the TODO list; take
> all the time you need to work on this, and thanks a lot for go after it
> with vigor.
Slow progress.
Here is a diff of the registers I know about on a fresh boot versus
after a Ctrl-Alt-Backspace. Not sure which are relev
On Thu, Apr 08, 2004 at 11:49:12PM -0400, Clint Adams wrote:
> > This patch seems good to me at first sight. I didn't test it obviously
> > though.
>
> Actually, there's something wrong. It doesn't work directly after a reboot;
> I have to restart the X server at least once for it to be okay.
Ok
> This patch seems good to me at first sight. I didn't test it obviously
> though.
Actually, there's something wrong. It doesn't work directly after a reboot;
I have to restart the X server at least once for it to be okay.
On Thu, Apr 08, 2004 at 03:03:01PM -0400, Clint Adams wrote:
> > > barely usable, so I would include it for now. If I manage to come up
> > > with anything that fixes the problem completely, it will no doubt depend
> > > on that patch.
> >
> > Okay. I just added a TODO item for this.
>
> The fo
> > barely usable, so I would include it for now. If I manage to come up
> > with anything that fixes the problem completely, it will no doubt depend
> > on that patch.
>
> Okay. I just added a TODO item for this.
The following patch helps immensely. In fact, I could be hallucinating,
but it s
On Thu, Apr 01, 2004 at 08:51:02AM +0200, Sven Luther wrote:
> On Thu, Apr 01, 2004 at 01:41:22AM -0500, Branden Robinson wrote:
> > On Wed, Mar 31, 2004 at 11:10:02AM -0500, Clint Adams wrote:
> > > > If your graphics controller is limited by memory bandwidth, the maximum
> > > > pixel
> > > > cl
On Thu, Apr 01, 2004 at 01:41:22AM -0500, Branden Robinson wrote:
> On Wed, Mar 31, 2004 at 11:10:02AM -0500, Clint Adams wrote:
> > > If your graphics controller is limited by memory bandwidth, the maximum
> > > pixel
> > > clock depends on the number of bits per pixels, since larger pixels mean
On Wed, Mar 31, 2004 at 11:10:02AM -0500, Clint Adams wrote:
> > If your graphics controller is limited by memory bandwidth, the maximum
> > pixel
> > clock depends on the number of bits per pixels, since larger pixels mean
> > more
> > memory bandwidth.
>
> I'm unclear on the differences betwee
On Wed, Mar 31, 2004 at 07:38:38PM -0500, Clint Adams wrote:
> > Do you want to continue working on this problem, or would you like to
> > see the patch you have prepared incorporated into unstable more or less
> > as-is?
>
> I am continuing to work on it with no noticeable success. The patch in
> Do you want to continue working on this problem, or would you like to
> see the patch you have prepared incorporated into unstable more or less
> as-is?
I am continuing to work on it with no noticeable success. The patch in
the bug report changes the second head from completely unusable to
bare
On Tue, Mar 30, 2004 at 10:32:47AM -0500, Clint Adams wrote:
> This patch helps, though the second head is still a bit fuzzy.
> One other thing I've noticed is that the clock range is detected
> by X as 16.25 to 110.00 MHz, though the board specs claim a max of
> 250MHz.
Do you want to continue wo
> If your graphics controller is limited by memory bandwidth, the maximum pixel
> clock depends on the number of bits per pixels, since larger pixels mean more
> memory bandwidth.
I'm unclear on the differences between 24 bpp and 32 bpp and how this
relates to internal pixmap format.
On Wed, 31 Mar 2004, Sven Luther wrote:
> On Tue, Mar 30, 2004 at 06:02:03PM -0500, Clint Adams wrote:
> > > I believe that the cloack is different for 8bpp and 16 or 24 bpp, don't
> > > remember exactly. At 8bpp, the max clock range is 230Mhz in the driver i
> > > think. You looked at it, you have
> I believe that the cloack is different for 8bpp and 16 or 24 bpp, don't
> remember exactly. At 8bpp, the max clock range is 230Mhz in the driver i
> think. You looked at it, you have the hardware, you just have become the
> resident expert on this issue :).
Ahh. I tried increasing the 32bpp num
On Tue, Mar 30, 2004 at 06:02:03PM -0500, Clint Adams wrote:
> > I believe that the cloack is different for 8bpp and 16 or 24 bpp, don't
> > remember exactly. At 8bpp, the max clock range is 230Mhz in the driver i
> > think. You looked at it, you have the hardware, you just have become the
> > resi
On Tue, Mar 30, 2004 at 10:32:47AM -0500, Clint Adams wrote:
> This patch helps, though the second head is still a bit fuzzy.
> One other thing I've noticed is that the clock range is detected
> by X as 16.25 to 110.00 MHz, though the board specs claim a max of
> 250MHz.
I believe that the cloack
This patch helps, though the second head is still a bit fuzzy.
One other thing I've noticed is that the clock range is detected
by X as 16.25 to 110.00 MHz, though the board specs claim a max of
250MHz.
diff -ruN xc-old/programs/Xserver/hw/xfree86/drivers/glint/glint_regs.h
xc/programs/Xserver/hw
> This will not help, X things everything is ok, it is just the graphic
> card output which is problematic. No way to find it in the log, you have
> to look at the way the graphic output registers are programmed.
Attached is XFree86.0.log after putting #define DEBUG 1 at the top of
pm2v_dac.c. F
> This will not help, X things everything is ok, it is just the graphic
> card output which is problematic. No way to find it in the log, you have
> to look at the way the graphic output registers are programmed.
>
> Look at the pm2_dac.c stuff.
Well, I haven't gotten as far as dumping the regis
> Ok. An OF driver then ?
I assume so.
> Nope, this is not the right way, you have to rebuild the driver and add
> some code to drop the content of the registers somewhere.
>
> I don't have time right now, maybe later i will find time to send you a
> register dropping patch or something.
Okay,
On Wed, Jan 14, 2004 at 04:12:46PM -0500, Clint Adams wrote:
> > You would dump all the possible registers, and see which one is
> > different. Enabling debugging in the glint driver would also do. You can
> > safely run no-accel on these for the tests, as this is definitively not
> > an accel issu
> Yep. It probably doesn't happen on x86, since the int10 stuff
> initializes the card with the onboard bios. Using a x86 emulator in X to
> run this bios might be a solution.
According to Tech-Source, this card has no VGA bios..
> Ho. definitively some registers who are bad. It has been a long t
> You would dump all the possible registers, and see which one is
> different. Enabling debugging in the glint driver would also do. You can
> safely run no-accel on these for the tests, as this is definitively not
> an accel issue, but a video out/ramdac one.
Here's the NoAccel version.
This is
On Wed, Jan 14, 2004 at 04:06:35PM -0500, Clint Adams wrote:
> > Yep. It probably doesn't happen on x86, since the int10 stuff
> > initializes the card with the onboard bios. Using a x86 emulator in X to
> > run this bios might be a solution.
>
> According to Tech-Source, this card has no VGA bios
On Tue, Jan 13, 2004 at 10:40:25AM -0500, Clint Adams wrote:
> > Ok, this may be the problem. The first one is initialized by the pm2fb,
> > while the second is not. This mean either some initialization problems,
> > or the fact that X doesn't initialize some values set by pm2fb.
>
> Sound sreason
> Ok, this may be the problem. The first one is initialized by the pm2fb,
> while the second is not. This mean either some initialization problems,
> or the fact that X doesn't initialize some values set by pm2fb.
Sound sreasonable.
> What kernel are you using, maybe it would be best to work on a
On Mon, Jan 12, 2004 at 04:55:43PM -0500, Clint Adams wrote:
> > Could you also provide the /var/log/XFree86.0.log, and please CC me on
> > this bugreport.
>
> Sure.I don't know if this is relevant, but the first card is is
> picked up by the PM2 framebuffer driver (the second is not, because
> Could you also provide the /var/log/XFree86.0.log, and please CC me on
> this bugreport.
Sure.I don't know if this is relevant, but the first card is is
picked up by the PM2 framebuffer driver (the second is not, because the
driver doesn't support multiple cards--I'm trying to copy the multi
On Fri, Jan 09, 2004 at 11:31:19AM -0500, Clint Adams wrote:
> Package: xserver-xfree86
> Version: 4.3.0-0pre1v3
> Severity: normal
>
> I have two TSI Raptor GFX 8P cards in a sparc machine. The left screen
> comes up at 1280x1024, with minimal random distortion and flicker. The
> right screen c
Package: xserver-xfree86
Version: 4.3.0-0pre1v3
Severity: normal
I have two TSI Raptor GFX 8P cards in a sparc machine. The left screen
comes up at 1280x1024, with minimal random distortion and flicker. The
right screen comes up at 1152x864, and is completely unusable. With
Xinerama on, the scr
33 matches
Mail list logo
