Re: How the screen to be Rotate 90deg

[Alex Deucher]

check the xfree86 or xorg devel mailing lists.  Someone posted a patch
for i8xx rotation (no accel, using shadowfb).

Alex

On Wed, 14 Jul 2004 11:52:42 +0530, NaggarajaVignesh.R
<[EMAIL PROTECTED]> wrote:
> Hi
> 
>   Iam trying to Rotate the Screen 90 in Red Hat Linux 9.0 with System
> Configuration intel 845 graphics card .The error msg is
> 
> X Error of failed request:  BadMatch (invalid parameter attributes)
>   Major opcode of failed request:  156 (RANDR)
>   Minor opcode of failed request:  2 (RRSetScreenConfig)
>   Serial number of failed request:  12
>   Current serial number in output stream:  12
> 
> can any one help me .
> 
> Thanks in advance
> 
> regards
> Vignesh
> 
> ___
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel
>
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

[ALPHA] Duoview support for mobile savages

[Alex Deucher]

At long last I've gotten duoview (dualhead) working with my savage IX! 
It should also work on MX and Supersavage chips, but I don't have the
hardware to test.  My current code is a bit of a hack, basically just 2
viewports into a big framebuffer.  There are no safeguards in the code
at the moment.  USE AT YOUR OWN RISK!  As I'm not (yet) able to change
the framebuffer offset on crtc2, only left of, above, and clone
orientations are supported right now.  Configuration notes and support
information as well as a patch and binary are available here:
http://www.botchco.com/alex/new-savage/html/
Full-fledged "regular" multi-head and MergedFB support as well as bug
fixes and new features will be added as I have time.

I want to thank Tim and Austin for their help on this.  I could not
have done it with out them.

Enjoy,

Alex
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: i855 crt out

[Alex Deucher]

Post you patches on either xfree86 or xorg bugzilla and we can take a
look at integrating them.  FWIW, the new intel DDX code drop in cvs
includes full multi-head support.  I'm not sure how that affects your
patches.

Alex

On Sun, 25 Jul 2004 15:09:18 +0200, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Hi!
> I'm the author of the little utility named i855crt.
> It's basically a little 'userspace sub-driver' that works in cooperation with
> X (and eventually the fb driver) to enable CRT out on Intel 855 laptop cards.
> It includes also two little patches for X to enable hw cursor on the CRT and
> to let the user choose to have xvideo on crt or LCD .
> I'm interested in evaluating and discussing the possibility to have some sort
> of integration with the X driver. Some people also asked me about it.
> The driver can be found on sourceforge named i855crt.
> It's released under GPL, i have no idea of what differ than X licence, since
> i'm not experienced with legal stuff.
> Anyway if someone is interested to discuss about it i will enjoy it.
> I'm not subrisbed to the mailing list, so *please CC me*.
> 
> Thanks,
> Andrea Merello
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: Maven on G550 - was Re: Matrox G550 true dual-dvi problem

[Alex Deucher]

On Thu, 23 Sep 2004 18:12:31 +0100 (BST), Andrew C Aitchison
<[EMAIL PROTECTED]> wrote:
> On Thu, 23 Sep 2004, Klaus Dittrich wrote:
> 
> > I put all noDDC options in the server flags and in both
> > monitor options as well.
> > But nothing helped, the hangs still happen.
> >
> > According to the log file (excerpt appended) the module
> > DDC is loaded and I2C bus "DDC P1" is initialized _before_
> > the options get recognized.
> 
> I'm seeing this on my G550-DVI-VGA now.
> 
> DDC P1 is part of Ryan Underwood's G400 Maven changes for the DDC support
> on the second head, but I'm discovering that this doesn't appear to work
> on G550s.
> 
> Does anyone know whether the G550 has a Maven "chip" ?

no.  it doesn't.  The second dac was integrated on the g540 and later models,

> If so we need to try to get it to work;
> if not we should disable this on the G550.
> 
> If I understand correctly, Ryan's change is intended to allow full
> feature support for the Dual head G400 (and G450 ?) *without* using
> Matrox's HAL.

It's a start it that direction.  all it does right now is fix DDC and
DPMS on the second of G400s.  The code to actually set up the mode on
the maven is still missing.

> I still can't get dual head on G550 to work without HAL, so DDC support
> is moot.

It should work without HAL.  I had it working on my G550 (dvi + vga) a
while back.

Alex

> 
> > So if the hang occurs during this initialisation there is
> > nothing to expect from the change.
> >
> > Is there an extended logging/debuging possible to find out what
> > really happens?
> >
> > The logs using DDC, after the hang, always looked fine. None of the
> > problems you described exhibited in the log files with both g550
> > variants.
> >
> > --
> > Klaus
> > ..
> > (II) LoadModule: "mga_hal"
> > (II) Loading /usr/local/X11R6/lib/modules/drivers/mga_hal_drv.o
> > (II) Module mga_hal: vendor="The XFree86 Project"
> > compiled for 4.3.0, module version = 1.0.0
> > ABI class: XFree86 Video Driver, version 0.6
> > (==) MGA(0): Matrox HAL module used
> > (**) MGA(0): Depth 24, (--) framebuffer bpp 32
> > (==) MGA(0): RGB weight 888
> > (**) MGA(0): Option "HWcursor" "Off"
> > (**) MGA(0): Option "PciRetry" "On"
> > (**) MGA(0): Option "Crtc2Half" "On"
> > (**) MGA(0): Option "AGPMode" "4"
> > (**) MGA(0): Option "DigitalScreen1" "Yes"
> > (**) MGA(0): Using AGP 4x mode
> > (**) MGA(0): PCI retry enabled
> > (--) MGA(0): Linear framebuffer at 0xFC00
> > (--) MGA(0): MMIO registers at 0xF010
> > (--) MGA(0): Pseudo-DMA transfer window at 0xF080
> > (==) MGA(0): BIOS at 0xC
> > (--) MGA(0): Video BIOS info block at offset 0x07CE0
> > (WW) MGA(0): Video BIOS info block not detected!
> > (II) MGA(0): MGABios.RamdacType = 0x0
> > (==) MGA(0): Write-combining range (0xfc00,0x200)
> > (**) MGA(0): Crtc2 will use 16384K of VideoRam
> > (--) MGA(0): VideoRAM: 16384 kByte
> > (II) Loading sub module "ddc"
> > (II) LoadModule: "ddc"
> > (II) Loading /usr/X11R6/lib/modules/libddc.a
> > (II) Module ddc: vendor="The XFree86 Project"
> > compiled for 4.4.99.13, module version = 1.0.0
> > ABI class: XFree86 Video Driver, version 0.7
> > (II) Loading sub module "i2c"
> > (II) LoadModule: "i2c"
> > (II) Loading /usr/X11R6/lib/modules/libi2c.a
> > (II) Module i2c: vendor="The XFree86 Project"
> > compiled for 4.4.99.13, module version = 1.2.0
> > ABI class: XFree86 Video Driver, version 0.7
> > (==) MGA(0): Write-combining range (0xfc00,0x100)
> > (II) MGA(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x
> > (II) MGA(0): I2C bus "DDC P1" initialized.
> > (**) MGA(0): Option "NoDDC1"
> > (**) MGA(0): Option "NoDDC"
> > (II) MGA(0): I2C Monitor info: (nil)
> > (II) MGA(0): end of I2C Monitor info
> > (II) MGA(0): DDC Monitor info: (nil)
> > (II) MGA(0): end of DDC Monitor info
> > (II) Loading sub module "vbe"
> > (II) LoadModule: "vbe"
> > ..
> > ___
> > Devel mailing list
> > [EMAIL PROTECTED]
> > http://XFree86.Org/mailman/listinfo/devel
> >
> 
> ___
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel
>
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: Maven on G550 - was Re: Matrox G550 true dual-dvi problem

[Alex Deucher]

On Thu, 23 Sep 2004 12:45:17 -0500 (CDT), Huver <[EMAIL PROTECTED]> wrote:
> Alex Deucher <[EMAIL PROTECTED]> writes:
> >
> > On Thu, 23 Sep 2004 18:12:31 +0100 (BST), Andrew C Aitchison
> > <[EMAIL PROTECTED]> wrote:
> >>
> >> I still can't get dual head on G550 to work without HAL, so DDC support
> >> is moot.
> >
> >It should work without HAL.  I had it working on my G550 (dvi + vga) a
> >while back.
> 
> How?  Please tell.  I'm running 4.4.0 (locally built) on a FreeBSD 4.10,
> G550 w/o HAL causes my monitor (DVI only) to say "No INPUT" and goes to
> sleep.

I don't remember. it was probably a year or two ago at this point.  I
don't have the card anymore.

Alex

> 
> With HAL, I get the "longer than 1 minute start up" 9 out of 10 times
> after "startx".
> 
> The "HAL" was built from using Matrox's HALLib in their linux driver kit for
> 4.3.0.  On FreeBSD, the "longer-than-1-minute start-up on DVI" happens with
> and without linux emulation loaded.
> 
> 
> -huver  [EMAIL PROTECTED]
> 
>
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: Documentation about drivers

[Alex Deucher]

On Fri, 19 Nov 2004 19:05:13 +0100, Måns Rullgård <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] writes:
> 
> >> [EMAIL PROTECTED] writes:
> >>
> >>> Hi,
> >>>
> >>> Where I can find the documentation about developing video driver
> >>> for XFree?? I'll need to develop one to a new card we working
> >>> on. Where can I find some info about it?
> >>
> >> xc/programs/Xserver/hw/xfree86/doc/DESIGN contains some useful
> >> information.  Looking at the source code of existing drivers can also
> >> be helpful.
> >
> > Is there anyway to compile drivers without compile whole XFree?
> 
> It should be possible.  You just need to make sure the required header
> files are found.  You'll need the XF86 sources, but there is no need
> to compile the whole lot.
> 

you can probably just run 
make Makefile
make Makefiles
make include
make depend

at the xc level and then just run 'make' in the directories of the
drivers you want to build.

Alex

> --
> Måns Rullgård
> [EMAIL PROTECTED]
>

___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: DRI Support for ATI Radeon 9550

[Alex Deucher]

On Wed, 19 Jan 2005 16:32:44 +0100, Grand Apeiron <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> i've just noted that the XFree86 radeon driver does not support DRI
> (at least not for 9500/9700 series and i have a 9550).
> I've also tried the ATI proprietary driver but giving up after it didn't
> work right away and noting that it doesn't support DRI on Xinerama
> setups.
> I am using XFree86 4.3.0 with Xinerama using the radeon card and an old
> matrox millenium 2.
> 
> So my current point is that there is no solution for me to get DRI
> support (or is there any solution?), and i want to ask if
> there is currently any planning regarding the implementation of DRI for
> that cards?
> Do you need any help regarding this?
> 
> Thank you and greetings from germany,
> Grand Apeiron
> 

there is experimental r300/r400 support going on here:
http://r300.sf.net
Note, at the moment there is no support with any X server for DRI with xinerama.

Alex
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: DRI Support for ATI Radeon 9550

[Alex Deucher]

On Wed, 19 Jan 2005 17:33:41 +0100, Grand Apeiron <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-01-19 at 10:58 -0500, Alex Deucher wrote:
> > there is experimental r300/r400 support going on here:
> > http://r300.sf.net
> > Note, at the moment there is no support with any X server for DRI with 
> > xinerama.
> >
> > Alex
> 
> Thank you very much for your answer.
> Does that mean you can't have DRI at all or you can have DRI only on the
> first screen but not on the second?
> 

not DRI at all with xinerama at the moment.  dualheaded radeon and sis
chips support a special option called mergedfb which gives you
dualhead with DRI. mutli-card 3d is not yet supported.

Alex
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: DRM kernel source broken/incomplete

[Alex Deucher]

On Tue, 8 Feb 2005 18:40:07 -0500, David Dawes <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 08, 2005 at 11:24:43PM +, Alan Hourihane wrote:
> >On Tue, Feb 08, 2005 at 06:17:50PM -0500, David Dawes wrote:
> >> On Tue, Feb 08, 2005 at 05:12:29PM +, Alan Hourihane wrote:
> >> >On Tue, Feb 08, 2005 at 11:59:15AM -0500, David Dawes wrote:
> >> >> On Tue, Feb 08, 2005 at 04:40:42PM +, Alan Hourihane wrote:
> >> >> >On Tue, Feb 08, 2005 at 11:32:56AM -0500, David Dawes wrote:
> >> >> >> It looks like the DRM kernel source in xc/extras/drm is broken and
> >> >> >> incomplete, especially for BSD platforms.  The Linux version only
> >> >> >> appears to build for a narrow range of kernels, and this either
> >> >> >> needs to be fixed, or the minimum kernel requirements enforced in
> >> >> >> the Makefile.
> >> >> >>
> >> >> >> Perhaps we'll have to roll back to an older version that does build?
> >> >> >
> >> >> >I suspect pulling in a newer snapshot would be better, although it's
> >> >> >a little more complicated now because the drm has split out support
> >> >> >for linux 2.4 and 2.6 kernels is separate subdirectories.
> >> >>
> >> >> Does the build automatically figure out which to use based on the
> >> >> kernel version, and what range of kernels has it been verified on?
> >> >
> >> >No.
> >>
> >> Any imports/updates need to address our requirements in this regard.
> >
> >If we import the current DRM trunk code, there are three linux directories.
> >
> >1. linux   for 2.4 kernels (monolithic)
> >2. linux-2.6   for 2.6 kernels (monolithic)
> >3. linux-core  for 2.6 kernels with modular drm.ko and .ko
> >
> >and two for bsd
> >
> >1. bsd monolithic
> >2. bsd-coremodular as above
> >
> >The -core are the new ones going forward and which I believe has been
> >merged in linux 2.6.11.
> >
> >So, for now the linux-2.6, linux and bsd directories are the ones to stick
> >with for stability. But things are changing.
> >
> >There'll be necessary build tweaks to select which directories are needed.
> 
> At this point in our release cycle, the priorities are:
> 
>   1st: It builds/runs and is reasonably stable on a good range of platforms.
>   2nd: It supports as many DRI features as possible consistent with the
>first priority.
> 
> I don't think that even changing from the existing single Linux directory
> to two different kernel-specific directories is appropriate at this point
> in our release cycle.  The time for such a change was before the feature
> freeze.
> 
> If what we have now is too broken to be fixed without major structural
> changes, then it will need to be rolled back.

why not just let the kernel provide the drm?  Most if not all recent
linux and bsd kernels (last few years) have drm support.  The dri and
ddx will adapt depending on what's available in the kernel.

Alex

> 
> David
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: x86 emulator bug

[Alex Deucher]

On Thu, 10 Feb 2005 10:08:20 -, Charles Dobson <[EMAIL PROTECTED]> wrote:
> I am not sure if I should post this here or on bugzilla.

post your patch in bugzilla.

Thanks,

Alex

> 
> While trying to get a Silicon Motion SM722 video controller
> working with Solaris, I have discovered a problem with the
> emulation of the SHLD and SHRD (double precision shift)
> instructions of the x86 emulator.
> According to the Intel Pentium User Guide Vol 3, these
> instructions can shift upto 31 bits with both 16 and 32
> bit operands. The emulator code will only work with shifts
> of upto 15 bits for 16 bit operands.
> 
> The file is
> xc/extras/x86emu/src/x86emu/prim_ops.c
> 
> I have modified the two functions as below.
> I am not positive the flags are set correctly so
> would appreciated someone else to check these.
> 
> u16 shld_word (u16 d, u16 fill, u8 s)
> {
> unsigned int cnt, res, cf;
> 
> if (s < 32) {
> cnt = s % 32;
> if (cnt > 0) {
> if (cnt > 15) {
> res = (unsigned int)fill << (cnt - 16);
> if (cnt == 16)
> cf = d & 0x1;
> else
> cf = res & 0x1;
> }
> else {
> res = (d << cnt) | (fill >> (16-cnt));
> cf = d & (1 << (16 - cnt));
> }
> CONDITIONAL_SET_FLAG(cf, F_CF);
> CONDITIONAL_SET_FLAG((res & 0x) == 0, F_ZF);
> CONDITIONAL_SET_FLAG(res & 0x8000, F_SF);
> CONDITIONAL_SET_FLAG(PARITY(res & 0xff), F_PF);
> } else {
> res = d;
> }
> if (cnt == 1) {
> CONDITIONAL_SET_FLAGres & 0x8000) == 0x8000) ^
>   (ACCESS_FLAG(F_CF) != 0)), F_OF);
> } else {
> CLEAR_FLAG(F_OF);
> }
> } else {
> res = 0;
> CONDITIONAL_SET_FLAG((d << (s-1)) & 0x8000, F_CF);
> CLEAR_FLAG(F_OF);
> CLEAR_FLAG(F_SF);
> SET_FLAG(F_PF);
> SET_FLAG(F_ZF);
> }
> return (u16)res;
> }
> 
> u16 shrd_word (u16 d, u16 fill, u8 s)
> {
> unsigned int cnt, res, cf;
> 
> if (s < 32) {
> cnt = s % 32;
> if (cnt > 0) {
> if (cnt > 15) {
> if (cnt == 16)
> cf = d & 0x8000;
> else
> cf = fill & (1 << (cnt - 17));
> res = fill >> (cnt - 16);
> } else {
> cf = d & (1 << (cnt - 1));
> res = (d >> cnt) | (fill << (16 - cnt));
> }
> CONDITIONAL_SET_FLAG(cf, F_CF);
> CONDITIONAL_SET_FLAG((res & 0x) == 0, F_ZF);
> CONDITIONAL_SET_FLAG(res & 0x8000, F_SF);
> CONDITIONAL_SET_FLAG(PARITY(res & 0xff), F_PF);
> } else {
> res = d;
> }
> 
> if (cnt == 1) {
> CONDITIONAL_SET_FLAG(XOR2(res >> 14), F_OF);
> } else {
> CLEAR_FLAG(F_OF);
> }
> } else {
> res = 0;
> CLEAR_FLAG(F_CF);
> CLEAR_FLAG(F_OF);
> SET_FLAG(F_ZF);
> CLEAR_FLAG(F_SF);
> CLEAR_FLAG(F_PF);
> }
> return (u16)res;
> }
> 
> Charles Dobson.
> Concurrent Technologies Plc.
> 
> ___
> Devel mailing list
> Devel@XFree86.Org
> http://XFree86.Org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: External CRT works on 1024x768 but LCD not. Please Help!!!

[Alex Deucher]

On Fri, 18 Feb 2005 09:12:01 -0800, Bukie Mabayoje <[EMAIL PROTECTED]> wrote:
>
> Read my comments in blue. And I am still looking into this. 
> 
> Nqnsome wrote: 
> Hi, 
> 
> Can someone help me, please!? 
> 
> I have a Compal CY27 laptop. The graphics chipset is (as reported by lspci):
> 
> :00:02.0 VGA compatible controller: Intel Corp. 82852/855GM 
> Integrated Graphics Device (rev 02) 
> :00:02.1 Display controller: Intel Corp. 82852/855GM Integrated 
> Graphics Device (rev 02) 
>  
> 
> 
> 
>  The 82852GM supports two independent display. You have one at 00:02:.0 and
> the other at 00:02.1. You are configured to use BusID  "PCI:0:2:0". I am not
> sure which video port 0:2:0 drivers. One thing you can try is change BusID 
> to "PCI:0:2:1". 

it should use 02.0.  .1 is just a placeholder for the windows drivers AFAIK.

Alex
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: External CRT works on 1024x768 but LCD not. Please Help!!!

[Alex Deucher]

On Fri, 18 Feb 2005 17:03:33 -0300, SLCB <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> Thanks a lot for replying, really!
> 
> > The 82852GM supports two independent display. You have one at 00:02:.0
> > and the other at 00:02.1. You are configured to use BusID
> > "PCI:0:2:0". I am not sure which video port 0:2:0 drivers. One thing
> > you can try is change BusID  to "PCI:0:2:1".I suspect the reason it
> > works is that your system have two graphics controller. And one of it
> > is the 350Mhz 24-bit RAMDAC that support a regular scan analog monitor.
> 
> Are these BusIDs related to the display pipes reported in the Xfree log:
> 
> ...
> (II) I810(0): Display Info: CRT: attached: TRUE, present: TRUE, size: 
> (800,600)
> (II) I810(0): Display Info: TV: attached: FALSE, present: TRUE, size: 
> (800,600)
> (II) I810(0): Display Info: DFP (digital flat panel): attached: FALSE, 
> present: FALSE, size: (0,0)
> (II) I810(0): Display Info: LFP (local flat panel): attached: TRUE, present: 
> TRUE, size: (1024,768)
> (II) I810(0): Display Info: TV2 (second TV): attached: FALSE, present: FALSE, 
> size: (0,0)
> (II) I810(0): Display Info: DFP2 (second digital flat panel): attached: 
> FALSE, present: FALSE, size: (0,0)
> (II) I810(0): Currently active displays on Pipe A:
> (II) I810(0):   CRT
> (II) I810(0): No active displays on Pipe B.
> ...
> 
> I mean:
> 
> Display Pipe A = BusID PCI:0:2:0
> Display Pipe B = BusID PCI:0:2:1
> 
> or vice-versa?

no.  the second one is just a placeholder for the windows drivers so you get:
Intel 82852GM Display controller
Intel 82852GM Display controller (secondary)
in the windows device manager.

you'll want to use the primary id for both heads.

Alex
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: External CRT works on 1024x768 but LCD not. Please Help!!!

[Alex Deucher]

On Fri, 18 Feb 2005 17:13:17 -0300, SLCB <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> Sorry, I forgot to comment one answer.
> 
> Bukie Mabayoje wrote:
> 
> > I suspect the reason it works is that your system have two graphics
> > controller. And one of it is the 350Mhz 24-bit RAMDAC that support a
> > regular scan analog monitor.
> 
> You mean the two BusIds/Pipes or really another card? If I had another
> card, I guess it would be reported by lspci, wouldn´t ?
> 
> Sorry again, but I could not find any reference in the log to any 350Mhz
> 24-bit RAMDAC card. Am I missing something?
> 

your chip has two display controllers and two outputs, a DAC for
analog out and a LCD controller for the laptop panel.  it's all
handled by one chip.

Alex

> Thanks again.
> 
> Regards,
> 
> Sergio
>

___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: External CRT works on 1024x768 but LCD not. Please Help!!!

[Alex Deucher]

On Fri, 18 Feb 2005 12:02:37 -0800, Bukie Mabayoje <[EMAIL PROTECTED]> wrote:
> 
> 
> Alex Deucher wrote:
> 
> > On Fri, 18 Feb 2005 17:03:33 -0300, SLCB <[EMAIL PROTECTED]> wrote:
> > > Hi,
> > >
> > > Thanks a lot for replying, really!
> > >
> > > > The 82852GM supports two independent display. You have one at 00:02:.0
> > > > and the other at 00:02.1. You are configured to use BusID
> > > > "PCI:0:2:0". I am not sure which video port 0:2:0 drivers. One thing
> > > > you can try is change BusID  to "PCI:0:2:1".I suspect the reason it
> > > > works is that your system have two graphics controller. And one of it
> > > > is the 350Mhz 24-bit RAMDAC that support a regular scan analog monitor.
> > >
> > > Are these BusIDs related to the display pipes reported in the Xfree log:
> > >
> > > ...
> > > (II) I810(0): Display Info: CRT: attached: TRUE, present: TRUE, size: 
> > > (800,600)
> > > (II) I810(0): Display Info: TV: attached: FALSE, present: TRUE, size: 
> > > (800,600)
> > > (II) I810(0): Display Info: DFP (digital flat panel): attached: FALSE, 
> > > present: FALSE, size: (0,0)
> > > (II) I810(0): Display Info: LFP (local flat panel): attached: TRUE, 
> > > present: TRUE, size: (1024,768)
> > > (II) I810(0): Display Info: TV2 (second TV): attached: FALSE, present: 
> > > FALSE, size: (0,0)
> > > (II) I810(0): Display Info: DFP2 (second digital flat panel): attached: 
> > > FALSE, present: FALSE, size: (0,0)
> > > (II) I810(0): Currently active displays on Pipe A:
> > > (II) I810(0):   CRT
> > > (II) I810(0): No active displays on Pipe B.
> > > ...
> > >
> > > I mean:
> > >
> > > Display Pipe A = BusID PCI:0:2:0
> > > Display Pipe B = BusID PCI:0:2:1
> > >
> > > or vice-versa?
> >
> > no.  the second one is just a placeholder for the windows drivers so you 
> > get:
> > Intel 82852GM Display controller
> > Intel 82852GM Display controller (secondary)
> > in the windows device manager.
> >
> > you'll want to use the primary id for both heads.
> 
> Alex is correct. Let focus on the primary display controller on  PCI:0:2:0 
> with Display Pipe A and Display Pipe B.
> In your case you can only have PipeA=CRT and PipeB=LCD (LFP).
> 
> That is why you have the following information
> (II) I810(0): Display Info: CRT: attached: TRUE, present: TRUE, size: 
> (800,600)
>  (II) I810(0): Display Info: LFP (local flat panel): attached: TRUE, present: 
> TRUE, size: (1024,768)
> 
> The problem is why XFree is saying there is no active display on Pipe B
>  (II) I810(0): No active displays on Pipe B

you can use the "monitorlayout" option to force on the pipes.  see the
i810 man page.

Alex

> 
> >
> >
> > Alex
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: External CRT works on 1024x768 but LCD not. Please Help!!!

[Alex Deucher]

On Fri, 18 Feb 2005 18:15:16 -0300, Nqnsome <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> Thanks again.
> 
> Alex Deucher wrote:
> 
> >>Alex is correct. Let focus on the primary display controller on  PCI:0:2:0 
> >>with Display Pipe A and Display Pipe B.
> >>In your case you can only have PipeA=CRT and PipeB=LCD (LFP).
> >>
> >>That is why you have the following information
> >>(II) I810(0): Display Info: CRT: attached: TRUE, present: TRUE, size: 
> >>(800,600)
> >> (II) I810(0): Display Info: LFP (local flat panel): attached: TRUE, 
> >> present: TRUE, size: (1024,768)
> >>
> >>The problem is why XFree is saying there is no active display on Pipe B
> >> (II) I810(0): No active displays on Pipe B
> >>
> >>
> >
> >you can use the "monitorlayout" option to force on the pipes.  see the
> >i810 man page.
> >
> >Alex
> >
> >
> Now I understand the "Pipes", but is still a mistery for me why lspci
> sees the 0:2:1, if it is a Windows "placeholder" (propably because I do
> not understand what a placeholder is...).
> 

when the windows driver claims the pci resources, it gives them each a
name and they show up in the windows device manager.  the second
"subfunction" is just there so they can have two video devices show up
in the device manager.

> Regarding the "No active displays on Pipe B", this probably happens
> because, before starting X, I disable the LCD with the keyboard sequence
> FN+F5. If I do not do this, the screen becomes unreadble (I guess
> because the CRT works in 1024x768 and the LCD do not).

that's the problem.  the i810 driver relies on the bios to deal with
outputs and modes.  if tyou use the bios to disable an ouput, the
driver probably has problems detecting an attached device.

> 
> Thanks a lot for the explanations, but I would like to return to the
> question "why the CRT works under 1024x768 and the LCD not". Can this be
> related to the VESA VBE DCC that does not work on the LCD?
> 

are you trying to get dualhead running or clone or just the LCD?

Alex


> Thanks again.
> 
> Regards,
> 
> Sergio
>
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: Fatal Error --? Video driver?

[Alex Deucher]

On 5/4/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > On Tue, May 03, 2005 at 05:18:28PM -0700, Tim Roberts wrote:
> >> [EMAIL PROTECTED] wrote:
> >>
> >> >devel@XFree86.Org
> >> >Hi I am trying to get XFree running on this configuration butno success
> >> so
> >> >far. It looks likevsomething to do with the on board video
> >> >
> >> >The motherboard is ABIT VA-20 (www.abit.com)
> >> >Integrated on board Unichrome Pro Graphics with 2D/3D/video controller
> >> >64 Meg of DDR ram allocated for video
> >> >Total ram 1G
> >> >
> >> >
> >>
> >> The VIA Unichrome chip does not have a driver built-in to XFree86.  VIA
> >> distributes one, but I don't know whether it plays with XFree86 4.5.0.
> >> Google for "xfree86 unichrome" for lots of hints.
> >>
> >> You should be able to run the vesafb driver.  You won't get
> >> acceleration, but it should work.
> >>
> >> --
> >> Tim Roberts, [EMAIL PROTECTED]
> >> Providenza & Boekelheide, Inc.
> >>
> > http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/drivers/via/
> > The files in there have xf-4_5 tags... And what's there should be
> > capable of running an X natively on a standard KM400 board.
> >
> > Luc Verhaegen.
> Thanks Luc -- but forgive me - my board is a VA-20 -- do you happen to know:
> (a) which one of the files I need AND
> (b) what do I have to do to get X11R6 to use it?
> 

you need to use the via driver that's available in xfree86.

Alex

> Thanks again
> 
> David
> NOTE
> Remove from my Reply-to - all before ["vizion" at "ixpres.com"] if
> emailing me
> 
> David Southwell  Ham call sign M0TAU
> 
> 40 yrs
> navigating and
> computing in
> blue waters.
> English Owner & Captain of British Registered 60' bluewater Ketch S/V
> Taurus. Currently in San Diego, CA. sailing May bound for Europe via
> Panama Canal.
> ___
> Devel mailing list
> Devel@XFree86.Org
> http://XFree86.Org/mailman/listinfo/devel
>

___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: [forum] Announce: xf86lite project: xplit xf86 into small pieces

[Alex Deucher]

On 6/1/05, Enrico Weigelt <[EMAIL PROTECTED]> wrote:
> * Stuart Anderson <[EMAIL PROTECTED]> wrote:
> 
> Hi,
> 
> >   I just wanted to make sure you were aware of the similar work
> > that has been underway for several months. Details can be found at
> >
> >   http://xorg.freedesktop.org/wiki/ModularizationWorkingGroup
> 
> Sounds interesting.
> 
> But is there anything actually available ?
> 
> I dont really have the time for long discussions, but need some parts
> (ie xlib) quite now. So I have to do it *now*.
> 
> 

yes, It's HEAVILY in progress now.  
http://wiki.x.org/wiki/ModularDevelopersGuide
http://wiki.x.org/wiki/ModularizationDevelPlan
http://www.freedesktop.org/Software/xlibs

Alex

> cu
> --
> -
>  Enrico Weigelt==   metux IT service
>   phone: +49 36207 519931 www:   http://www.metux.de/
>   fax:   +49 36207 519932 email: [EMAIL PROTECTED]
> -
>   Realtime Forex/Stock Exchange trading powered by postgresSQL :))
> http://www.fxignal.net/
> -

___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: Sun Creator and XRender

[Alex Deucher]

On 10/16/05, Michael <[EMAIL PROTECTED]> wrote:
> Hello,
>
> > > since the sunffb driver doesn't support the XRender extension but
> > > the graphics processor supports alpha blending and a few other nice
> > > tricks I've been poking around a bit to add this sort of
> > > functionality. The problem seems to be that sunffb doesn't use xaa
> > > or the standard framebuffer manager. so I couldn't get the included
> > > render code to work.
> > > So my questions are:
> > > - is there a text somewhere describing how to add xrender
> > > functionality to a driver without using fbPictureInit() ?
> > > - is there some more comprehensive ffb documentation available
> > > somewhere? I think I know how alpha blending and so on is supposed
> > > to work ( from reading the mesa driver source ) but there are still
> > > a few more questions.
> >
> > This has already been done in X.Org's repository and it is on my
> > to-do-soon list to merge in.
>
> Nice :)
> So I'll stop reinventing the wheel, wait until you're done and then
> import the result into NetBSD.
> I wonder if they fixed DRI support too.
>

DRI should work with xorg and mesa from cvs.

Alex

> have fun
> Michael
>
>
>

___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: Xorg and Cue Problems

[Alex Deucher]

On 10/19/05, Rick Knight <[EMAIL PROTECTED]> wrote:
> I've done some more testing and the problem seems to actually be with
> KDE. If I start Xorg in failsafe mode and scan in the Xterm window, I
> can see the Cuecat's output. Also, if I open an xterm in KDE, not a KDE
> term, I can still scan. It seems that KDE is grabbing the CueCat's
> input, but I can't find anything in the KDE control center, so I guess
> I'll try a KDE group.
>

KDE must be intercepting the Alt-F10 or whatever the cuecat sends first.

Alex

> Thanks,
> Rick Knight

___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: Multiple Xv overlays cause blue flashing

[Alex Deucher]

On 11/16/05, Smoof . <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I am writing an application that will display up to 9 independent video
> streams (each stream is 320 x 240).  I'm new to Xv and may not be using the
> correct terminology so please bear with me.  I have tried two approaches:
>
> The first approach was to create one large overlay using XvShmCreateImage
> and tile in the video frames.  Once all frames are tiled in, use
> XvShmPutImage to send them to the X server.  This method works perfectly.
> However, my ultimate goal is to send each video stream to it's own GTK
> widget so I can have each video stream playing in a window that can be
> moved, be surrounded by buttons, minimized, etc...
>
> I implemented this by creating a simple GTK app with three drawing areas
> (ultimately I will have 9) of 320x240 and used some GDK functions to
> determine the X window id's for the widgets.  I created a separate overlay
> (again using  XvShmCreateImage) for each window.  Then I call XvShmPutImage
> once for each window.  Finally I call XFlush so send the requests to the X
> server.  I tried using XSync but it seemed to interfere with the GTK event
> loop.
>
> The problem with this second approach is that the overlays are flashing blue
> (the overlay color key from what I've read).  So I looking for advice on how
> to update multiple overlays at a rate of 24fps without any flashing.  Or if
> you don't think this is possible then please let me know and I'll just have
> to get by with my first implementation.
>

Most hardware only has one overlay so each widget will be fighting for
it.  only the one that has it at any given moment will actually
display the video; the rest will show the colorkey.

Alex

> Thanks for your help
>

___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: Multiple Xv overlays cause blue flashing

[Alex Deucher]

On 11/16/05, Smoof . <[EMAIL PROTECTED]> wrote:
> >Smoof . wrote:
> >
> >>
> >>My plan was to do all the rendering with the same client and I know that
> >>my overlay adaptor only has a single port for the YUV420 format that I am
> >>using.  Can someone say if the following would be possible:
> >>
> >>Suppose I create a single overlay that is the size of the entire screen.
> >>Then I could track the absolute position and visibility of the individual
> >>widget windows I want to send the video streams to.  I would then tile in
> >>the images into the correct spot in the overlay to match the window
> >>position.  Now, if there were some way of using the alpha channel to only
> >>cause the certain portions of the overlay to be seen then that might do
> >>the trick.  Or could I just manually fill the areas I want to expose with
> >>the color key?  Please keep in mind that I really don't know what I'm
> >>talking about and have no idea if this is possible but it sounds like the
> >>only way to prevent the flashing is to use a single overlay and somehow
> >>figure out how to share it among the widget windows.
> >
> >
> >Does your graphics card support OpenGL?  One practical alternative is to
> >render the movies into textures.
> >
>
> Yes, I ran the SDL GL test program (testgl) and here is the output
>
> Screen BPP: 32
>
> Vendor : Mesa project: www.mesa3d.org
> Renderer   : Mesa GLX Indirect
> Version: 1.3 Mesa 4.0.4
> Extensions : GL_ARB_imaging GL_ARB_multitexture GL_ARB_texture_border_clamp
> GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine
> GL_ARB_texture_env_dot3 GL_ARB_transpose_matrix GL_EXT_abgr
> GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_subtract
> GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3
> GL_EXT_texture_lod_bias
>

this is software OpenGL.

> I don't know anything about openGL or textures but I'll start doing some
> research.
>
> I should have mentioned earlier that for this project I can specify any
> video card I want.  So if someone has a suggestion of what would be the best
> video card for this type of application please let me know.
>
> Thanks for the help.
>
>

many graphics cards even support YUV textures.  mesa has an extension
to expose that functionality (MESA_ycbcr_texture, IIRC)

Alex

___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: portrait mode how to

[Alex Deucher]

If you have a monitor that is natively portrait or will support a
portrait mode, then you can just define a 768x1024 modeline and
assuming the driver doesn't rely on the bios (since I doubt any bios
will have a mode like that defined) it will set the mode.  However, if
the monitor you are trying to use is natively landscape and only
supports landscape modes, then you will need to use rotation.  None of
the Xorg servers support xrandr rotation in 6.8.x, however, several of
the drivers have a driver specific "rotate" option that will provide
non-accelerated rotation.

Alex

On 11/28/05, krish ritik <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am working on X11R6.8.2. Just trying to explore if there is any posibility
> to put screen in portrait mode. I know about Nvidia driver. but i want to
> try it by myself.
>
> any hints how to put screen in 786x1024 mode (take the example of Intel
> card). I don;t need icon rotation and all. but just want to set the mode as
> 768x1024.
>
> regards,
> Puneet

___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: I810 driver and XVIDEO for HD movies fails

[Alex Deucher]

On 11/28/05, Barry Scott <[EMAIL PROTECTED]> wrote:
> I'm seeing this error when I attempt to play a HD 720p (1280x720) movie
> in Xine:
>
> X Error of failed request:  BadAlloc (insufficient resources for operation)
>   Major opcode of failed request:  143 (XVideo)
>   Minor opcode of failed request:  19 ()
>   Serial number of failed request:  609
>   Current serial number in output stream:  610
>
> I'm using Xfree86 4.5.0 on a Commel LV-670 board.
>
> lspci -v reports:
>
> 00:02.0 VGA compatible controller: Intel Corporation
> 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 03)
> (prog-if 00 [VGA])
> Subsystem: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset
> Integrated Graphics Device
> Flags: bus master, fast devsel, latency 0, IRQ 5
> Memory at d000 (32-bit, prefetchable) [size=128M]
> Memory at dc20 (32-bit, non-prefetchable) [size=512K]
> Capabilities: [d0] Power Management version 1
>
> 00:02.0 Class 0300: 8086:2562 (rev 03)
> Subsystem: 8086:2562
> ...
>
> I've added a VideoRAM 65536 to the device section but that not changed
> things.
> I'm also trying to track down where in the code the BadAlloc is being
> return with
> little success so far. I thought I had found that I should be in
> I810PutImage() in
> i810_video.c but the xf86DrvMsg call I make does not appear in the log
> of the
> servers stdout.
>
> What is the reason that the BadAlloc is being returned? What can I do
> about it?
> What more info can I provide?
>

try disabling the DRI.  The 3d driver may be grabbing most of the vram
and not leaving much for the server.

Alex

> Barry
>

___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: SM501 driver support in XFree86

[Alex Deucher]

On 2/6/06, Kaliraj Kalaichelvan - CTD, Chennai <[EMAIL PROTECTED]> wrote:
> I am using XFree86 Version 4.3.0. I understand from driver folder
> (\xc\programs\Xserver\hw\xfree86\drivers\siliconmotion)that silicon motion
> driver supports for SM720, SM910, SM810, SM820, SM710, SM712. Does this same
> silicon motion driver in xfree86 4.3.0 work fine for SM501? If not where
> shall i get the SM501 driver for Xfree86 4.3.0.?
>

Silicon motion added 501 support in xfree86 bugzilla, however, the
code was never integrated.  you can still grab the tarball there.  I
don't recall the bugzilla number off hand.

Alex


> Kali
> DISCLAIMER
> This message and any attachment(s) contained here are information that is 
> confidential, proprietary to HCL Technologies
> and its customers. Contents may be privileged or otherwise protected by law. 
> The information is solely intended for the
> individual or the entity it is addressed to. If you are not the intended 
> recipient of this message, you are not authorized to
> read, forward, print, retain, copy or disseminate this message or any part of 
> it. If you have received this e-mail in error,
> please notify the sender immediately by return e-mail and delete it from your 
> computer
>
>

___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: SM501 driver support in XFree86

[Alex Deucher]

On 2/7/06, Kaliraj Kalaichelvan - CTD, Chennai <[EMAIL PROTECTED]> wrote:
> Hello Alex,
> Thank you for the directive. I have downloaded the tarball. I have a concern
> - the tarball is for Linux x86 platform. I believe that it supports PCI/AGP
> SM501. Provide your views if i need to port that for a non-x86 platform with
> memory mapped SM501. I currently have a SH4 processor with SM501 memory
> mapped.
>

there are endian issues, IIRC, see the patches and discussion here:
https://bugs.freedesktop.org/show_bug.cgi?id=312

Alex

>
> -
> Kaliraj Kalaichelvan
>
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf
> Of Alex Deucher
> Sent: Wednesday, February 08, 2006 2:55 AM
> To: devel@xfree86.org
> Subject: Re: SM501 driver support in XFree86
>
>
> On 2/6/06, Kaliraj Kalaichelvan - CTD, Chennai <[EMAIL PROTECTED]> wrote:
> > I am using XFree86 Version 4.3.0. I understand from driver folder
> > (\xc\programs\Xserver\hw\xfree86\drivers\siliconmotion)that silicon motion
> > driver supports for SM720, SM910, SM810, SM820, SM710, SM712. Does this
> same
> > silicon motion driver in xfree86 4.3.0 work fine for SM501? If not where
> > shall i get the SM501 driver for Xfree86 4.3.0.?
> >
>
> Silicon motion added 501 support in xfree86 bugzilla, however, the
> code was never integrated.  you can still grab the tarball there.  I
> don't recall the bugzilla number off hand.
>
> Alex
>
>
> > Kali
> > DISCLAIMER
> > This message and any attachment(s) contained here are information that is
> confidential, proprietary to HCL Technologies
> > and its customers. Contents may be privileged or otherwise protected by
> law. The information is solely intended for the
> > individual or the entity it is addressed to. If you are not the intended
> recipient of this message, you are not authorized to
> > read, forward, print, retain, copy or disseminate this message or any part
> of it. If you have received this e-mail in error,
> > please notify the sender immediately by return e-mail and delete it from
> your computer
> >
> >
>
> ___
> Devel mailing list
> Devel@XFree86.Org
> http://XFree86.Org/mailman/listinfo/devel
>

___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: i945G 1280x768 sync polarity bug

[Alex Deucher]

On 6/12/06, Barry Scott <[EMAIL PROTECTED]> wrote:

Barry Scott wrote:
> Using the Xfree86 4.6.0 i810 driver I'm seeing a problem with sync
> polarity setting.
>
> This modeline is required for 1280x768 mode:
>
> Modeline "1280x768"   79.30  1280 1335 1473 1665  768 769 772 793
> -hsync +vsync
>
> But the syncs, as shown on an oscilloscope are +hsync +vsync.
>
> I added debug messages to show the Flags used. And here is a section
> of the log:
>
> (II) I810(0): Not using built-in mode "1280x1024" (height too large
> for virtual size)
> (II) I810(0): Not using built-in mode "1360x768" (width too large for
> virtual size)
> (II) I810(0): Increasing the scanline pitch to allow tiling mode (1280
> -> 2048).
> (--) I810(0): Virtual size is 1280x768 (pitch 2048)
> (**) I810(0): *Built-in mode "1280x768"
> (**) I810(0):  Built-in mode "1024x768"
> (**) I810(0):  Built-in mode "800x600"
> (**) I810(0):  Built-in mode "640x480"
> (II) I810(0): Attempting to use 60.06Hz refresh for mode "1280x768" (85a)
> (II) I810(0): I830SetModeParameters() Flags pMode->Flags 0x6
> block->Flags 0x4
> (II) I810(0): Attempting to use 75.08Hz refresh for mode "1024x768" (854)
> (II) I810(0): I830SetModeParameters() Flags pMode->Flags 0x5
> block->Flags 0x0
> (II) I810(0): Attempting to use 75.00Hz refresh for mode "800x600" (852)
> (II) I810(0): I830SetModeParameters() Flags pMode->Flags 0x5
> block->Flags 0x0
> (II) I810(0): Attempting to use 75.00Hz refresh for mode "640x480" (850)
> (II) I810(0): I830SetModeParameters() Flags pMode->Flags 0xa
> block->Flags 0xc
>
> This shows that the I830SetModeParameters() has the correct values in
> but pMode-Flags
> and block->Flags.
>
> I have also tested other modes as listed here
>
> ModeFlags   Syncs on wire
> 640x4800xC -hsync -vsync
> 800x6000x0 +hsync +vsync
> 1024x7680xC -hsync -vsync
> 1280x1024   0x0 +hsync +vsync
> 1280x7680x4 +hsync +vsync
>
> As you can see all the Syncs track the Flags except 1280x768.
>
> Looking at the VBE code it seems that as long as the Flags are
> defined correctly by the driver then its down to the INT10 BIOS
> to set the syncs on the hardware.
>
> Do you think this is a BIOS bug or a driver bug?
>
> Barry
I've just noticed that the refresh rate is 52.73Hz not 60Hz as expected.
Clearly the mode is not being honored.


The i810 driver is limited to the modes the bios knows how to set.  If
the bios doesn't have the specific mode you are lookign for, then you
are out of luck.  There is native modesetting support in the xorg
intel driver git tree if you want native modesetting.

Alex


Barry


___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: i945G 1280x768 sync polarity bug

[Alex Deucher]

On 6/13/06, Barry Scott <[EMAIL PROTECTED]> wrote:

Tim Roberts wrote:
> Barry Scott wrote:
>
>
>> Using the Xfree86 4.6.0 i810 driver I'm seeing a problem with sync
>> polarity setting.
>>
>> This modeline is required for 1280x768 mode:
>>
>> Modeline "1280x768"   79.30  1280 1335 1473 1665  768 769 772 793
>> -hsync +vsync
>>
>> But the syncs, as shown on an oscilloscope are +hsync +vsync.
>>
>
>
> Does this matter any more?  I thought the relevance of sync polarity
> ended in the middle of the Clinton administration.
>
Good question. We note that the EDID data wants these sync polarities.
Does the monitor use the pulse widths or the polarity to tell one mode
from another? We think that the polarity is used, but we are far from
certain.

>> Looking at the VBE code it seems that as long as the Flags are
>> defined correctly by the driver then its down to the INT10 BIOS
>> to set the syncs on the hardware.
>>
>> Do you think this is a BIOS bug or a driver bug?
>>
>
>
> It may be an expectations bug.  As you note, the Intel driver, like the
> Savage driver, relies on the BIOS to set the mode.  The BIOS has a
> limited set of video modes, with canned parameters for each timing.  It
> is not infinitely variable.  If the BIOS thinks 1280x768 should have
> positive syncs, then you are going to get positive syncs
I'm using 915resolution to add 1280x768 and 1360x768 into the BIOS.

It seems that if there is an entry in the BIOS for 1280x768 then the driver
is happy to to call INT10 to pass in the timings and sync polarity data.

If as you say the BIOS timings are the only ones used then what is the point
of the INT10 call to pass in the timings?



I'm not familiar with the i810's bios interface, but no other chip
I've ever worked on has allowed me to specify exact timings via the
BIOS.  It's usually either a VESA mode number or a size and a refresh
rate.  I doubt the i810 is much different, especially since most i810
bioses don't even support modes like 1280x768 out of the box.

Alex


Barry


___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: i945G 1280x768 sync polarity bug

[Alex Deucher]

On 6/14/06, Barry Scott <[EMAIL PROTECTED]> wrote:

Alex Deucher wrote:
>
> The i810 driver is limited to the modes the bios knows how to set.  If
> the bios doesn't have the specific mode you are lookign for, then you
> are out of luck.  There is native modesetting support in the xorg
> intel driver git tree if you want native modesetting.
Do you know if this code made it into a released version of Xorg yet?
I'll try and build the Xorg code against XFree86 and see what happens.


Nope.  It's still in the modesetting branch of the intel driver git tree:
http://gitweb.freedesktop.org/?p=xorg-driver-xf86-video-intel;a=summary

Alex



Barry


___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: x86emu emulation problem

[Alex Deucher]

On 10/5/06, jf simon <[EMAIL PROTECTED]> wrote:

Hi,
I am trying to use the x86emu code to emulate a PCI ATI Radeon
VGA bios on a powerpc platform (IBM 970 Maple).
The emulation starts OK, but after some time I can see that it is
making a call to a location that is outside of the VGA bios.
Which causes x86emu to emulate whatever rabbish it finds here.

At first I thought that maybe x86emu was emulating the wrong code
(maybe got misaligned in the opcodes). But using the "ndisasm"
x86 disassembler on the original VGA bios showed that x86emu was
emulating the code correctly.

I  have also compared PCI traces (collected with a H/W analyser)
ran on  the powerpc system and on a AMD64 system (which runs the
VGA BIOS OK) and I can see that x86emu on the powerpc is making
the right PCI accesses to the ATI before it crashes. Which makes
me thing the x86emu is working OK, at least at the beginning.

The problem is on the "call 0xe903" instruction. There is no code
there (code is from c: to c:0d000 ). Plus there are
those strange  opcodes "ENTER 8000,15", which are causing the SP
to go from SP=DFD0, to SP=5fa4 (righ in the code!). I have read
that the ENTER opcode was designed to make for high level
language procedures, and their required stack frame needs. But
0x8000 seems like a lot!

I am really at a loss so as what to do next...


FWIW, many video card bioses mess with PCI registers and the like.

Alex



Thaks for any help,
-jf simon



1- the x86emu trace just before the problem:
cat trace.cpu

c000:68dd a00080  MOV   AL,[8000]
 AX=  BX=01e3  CX=4100  DX=f004  SP=dfd0  BP=0197
SI=  DI=
 DS=  ES=c000  SS=c000  CS=c000  IP=68e2   NV UP DI
PL ZR NA PE NC
c000:68e0 04f5ADD   AL,f5
[BP+SI]AL   AX=00f5  BX=01e3  CX=4100  DX=f004  SP=dfd0
BP=0197  SI=  D
I=
 DS=  ES=c000  SS=c000  CS=c000  IP=68e4   NV UP DI
NG NZ NA PE NC
c000:68e2 0002ADD   ,
 AX=00f5  BX=01e3  CX=4100  DX=f004  SP=dfd0  BP=0197
SI=  DI=
 DS=  ES=c000  SS=c000  CS=c000  IP=68e8   NV UP DI
NG NZ AC PO CY
c000:68e4 c8008015ENTER 8000
,15
 AX=00f5  BX=01e3  CX=4100  DX=f004  SP=5fa4  BP=dfce
SI=  DI=
 DS=  ES=c000  SS=c000  CS=c000  IP=68e9   NV UP DI
NG NZ AC PO CY
c000:68e8 0e  PUSH  CS
[00c8]AXAX=00f5  BX=01e3  CX=4100  DX=f004  SP=5fa2
BP=dfce  SI=  D
I=
 DS=  ES=c000  SS=c000  CS=c000  IP=68ed   NV UP DI
NG NZ AC PO CY
c000:68e9 0106c800ADD   ,
[BX+SI] AX=00f5  BX=01e3  CX=4100  DX=f004  SP=5fa2  BP=dfce
SI=  DI=
 DS=  ES=c000  SS=c000  CS=c000  IP=68f0   NV UP DI
PL NZ NA PE NC
c000:68ed 80100e  ADC   BYTE PTR ,e
[DI]AX  AX=00f5  BX=01e3  CX=4100  DX=f004  SP=5fa2  BP=dfce
SI=  DI=
 DS=  ES=c000  SS=c000  CS=c000  IP=68f2   NV UP DI
PL NZ NA PO NC
c000:68f0 0105ADD   ,
 AX=00f5  BX=01e3  CX=4100  DX=f004  SP=5fa2  BP=dfce
SI=  DI=
 DS=  ES=c000  SS=c000  CS=c000  IP=68f6   NV UP DI
PL NZ NA PE NC
c000:68f2 c800800bENTER 8000
,b
 AX=00f5  BX=01e3  CX=4100  DX=f004  SP=df8a  BP=5fa0
SI=  DI=
 DS=  ES=c000  SS=c000  CS=c000  IP=68f7   NV UP DI
PL NZ NA PE NC
c000:68f6 0e  PUSH  CS
[SI]AX  AX=00f5  BX=01e3  CX=4100  DX=f004  SP=df88  BP=5fa0
SI=  DI=
 DS=  ES=c000  SS=c000  CS=c000  IP=68f9   NV UP DI
PL NZ NA PE NC
c000:68f7 0104ADD   ,
 AX=00f5  BX=01e3  CX=4100  DX=f004  SP=df88  BP=5fa0
SI=  DI=
 DS=  ES=c000  SS=c000  CS=c000  IP=68fd   NV UP DI
PL NZ NA PO NC
c000:68f9 c8008006ENTER 8000

 AX=00f5  BX=01e3  CX=4100  DX=f004  SP=5f7a  BP=df86
SI=  DI=
 DS=  ES=c000  SS=c000  CS=c000  IP=68fe   NV UP DI
PL NZ NA PO NC
c000:68fd 0e  PUSH  CS
[BP+SI]AX   AX=00f5  BX=01e3  CX=4100  DX=f004  SP=5f78
BP=df86  SI=  D
I=
 DS=  ES=c000  SS=c000  CS=c000  IP=6900   NV UP DI
PL NZ NA PO NC
c000:68fe 0102ADD   ,
 AX=00f5  BX=01e3  CX=4100  DX=f004  SP=5f78  BP=df86
SI=  DI=
 DS=  ES=c000  SS=c000  CS=c000  IP=6903   NV UP DI
PL NZ NA PE NC

c000:6900 e80080  CALL  e903   !!PROBLEM HERE!!

[BX+SI]AL   AX=00f5  BX=01e3  CX=4100  DX=f004  SP=5f76
BP=df86  SI=  D
I=
 DS=  ES=c000  SS=c000  CS=c000  IP=e905   NV UP DI
PL NZ NA PE NC
c000:e903 ADD   ,
[BX+SI]AL

(x86emu starts emulating bad codes (all zeroes)

  AX=00f5  BX=01e3  CX=4100  DX=f004  SP=5f76  BP=df86  SI=  D
I=
 DS=  ES=c000  SS=c000  CS=c000  IP=e907   NV UP DI
PL NZ AC PE CY
c000:e905 ADD   ,



2- The same code as seen from ndisasm:

68DA  A00080mov al,[0x8000]
6

Re: siliconmotion CSync output ?

[Alex Deucher]

On 3/8/07, bruno schwander <[EMAIL PROTECTED]> wrote:

ah never mind. since this is interlaced, the pixel clock needs to be half
that to get the right frame refresh rate (60Hz) with a pixel clock of
12.22MHz, it passes.

Now, I am not sure if the pixel clock is effectively set to that, and my
lcd still does not sync, so either the pixel clock is not set right or the
SMI712 is not outputting composite sync (despite my hack to enable it)

Time to get the oscilloscope out...



The siliconmotion driver doesn't explicitly set the vclk pll.  It uses
the bios (if UseBIOS is set or does nothing if not).  It's trivial to
add however. SR6C, SR6D are programmed similarly to the mclk.

Alex


Bruno

On Wed, 7 Mar 2007, bruno schwander wrote:

> ah actually now it is not choosing my modeline and I do not understand why:
>
> (II) Silicon Motionlg: Using hsync range of 14.00-80.00 kHz
> (II) Silicon Motionlg: Using vrefresh range of 56.00-76.00 Hz
> (II) Silicon MotionClock range:  14.00 to 135.00 MHz
> (II) Silicon MotionMode: 640x480 16-bpp, 59.990181Hz
> (II) Silicon MotionNot using mode "640x480i" (vrefresh out of range)
> (II) Silicon MotionMode: 640x350 16-bpp, 85.079948Hz
> (II) Silicon MotionNot using default mode "640x350" (vrefresh out of range)
>
>
> vrefresh range is 56-76Hz, so why is my 640x480i modeline, at 59.99Hz
> vrefresh, rejected ?
>
> the modeline is as follows:
>
>  ModeLine "640x480i" 24.44 640 680 728 776 480 480 484 525 Interlace
> Composite
>
>
>
> bruno
>
>
> On Wed, 7 Mar 2007, bruno schwander wrote:
>
>> I think I figured it out, however it seems that although my modeline
>> includes 'composite'
>>
>> DisplayModePtr mode->Flags & V_CSYNC
>>
>> does not evaluate to true. I assume as long as the 'composite' keyword is
>> found on the modeline, the flag should be set, right ?
>>
>> I need to add some debug messages, but this seems a little strange. Is
>> there something else that needs to be configured, like telling that the
>> driver actually supports the composite keyword on the modeline ?
>>
>> On a different note, the latest X release does not seem to work on that
>> chip. I just get a blank screen. So I started hacking on Xorg 6.8.2 to test
>> this stuff. I figure XFree86 4.5 should work, but 4.6 does not.
>>
>> I'll provide patches to all and note on which version it was tested of
>> course, once it works :-)
>>
>> bruno
>>
>> On Tue, 27 Feb 2007, Marc Aurele La France wrote:
>>
>>> On Sun, 25 Feb 2007, bruno schwander wrote:
 On Fri, 23 Feb 2007, Marc Aurele La France wrote:
> On Thu, 22 Feb 2007, bruno schwander wrote:
>> A little background: I have a single board PC with a SMI712 (lynxEM+)
>> graphic chipset. X works like a charm.
>>>
> The driver currently ignores the V_CSYNC mode flag, so you would need to
> come up with a source patch to change that.
>>>
 I'd be happy to provide a patch, if I can figure where to put that. Since
 it is only a matter of setting one register it should be simple enough. I
 have (had?) no idea where to start, I'll grep for V_CSYNC and see...
>>>
>>> An appropriate spot for such changes would be after calls to vgaHWInit(),
>>> which, in this case, is in SMI_ModeInit().
>>>
>>> Marc.
>>>
>>> +--+--+
>>> |  Marc Aurele La France   |  work:   1-780-492-9310  |
>>> |  Academic Information and|  fax:1-780-492-1729  |
>>> |Communications Technologies   |  email:  [EMAIL PROTECTED] |
>>> |  352 General Services Building   +--+
>>> |  University of Alberta   |  |
>>> |  Edmonton, Alberta   |Standard disclaimers apply|
>>> |  T6G 2H1 |  |
>>> |  CANADA  |  |
>>> +--+--+
>>> XFree86 developer and VP.  ATI driver and X server internals.

___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: siliconmotion CSync output ?

[Alex Deucher]

On 3/9/07, bruno schwander <[EMAIL PROTECTED]> wrote:

I keep answering my own questions. I hopI am not spamming the mailing list
too much, but it's nice to get some degree of confirmation from those who
know before I dive into something.

so I gather now that actually I should leave the xf86SetCrtcForModes()
alone, and just add setting the clock with CCR6C, CCR6D (and enabling it
with CCR68). I'll see how that goes...



exactly.  Sorry for not responding earlier.  You can use the
SMI_CalcClock() function to calculate SR6C and SR6D, just like the
mclk is generated. Use mode->Clock.  I have a similar patch in my xorg
smi tree.

Alex



bruno

On Thu, 8 Mar 2007, bruno schwander wrote:

> On Thu, 8 Mar 2007, Alex Deucher wrote:
>
>> The siliconmotion driver doesn't explicitly set the vclk pll.  It uses
>> the bios (if UseBIOS is set or does nothing if not).
>
>
> that is what I was wondering...
> well, if I do not
>
> Options UseBIOS  false
>
> all I get is a blank screen. So I have to disable it. I did not realize that
> it did not set the pixel clock since when using a default VGA 640x480
> resolution, it was working. So I guess it just happens to stay at whatever
> pixel clock the BIOS or console driver had set it to ? That seems very
> strange.
>
>> It's trivial to add however. SR6C, SR6D are programmed similarly to the
>> mclk.
>
> I saw that mclk/dac stuff, yes, and was wondering how the pixel clock was
> really set. All this makes more sense now.
>
> So what you are saying is that in smi_driver.c : SMI_PreInit(), I should
> replace the call to xf86SetCrtcForModes(pScrn, 0), with an alternative that
> programs vclk explicitely ?
>
> How can it set the crtc for several modes ? That is what
> xf86SetCrtcForModes() seems to do, right ?
>
> I still have a lot to learn.
>
> thanks for all the help guys, trudging along...
>
> bruno
>
>
>
>> Alex
>>
>>> Bruno
>>>
>>> On Wed, 7 Mar 2007, bruno schwander wrote:
>>>
>>> > ah actually now it is not choosing my modeline and I do not understand
>>> why:
>>> >
>>> > (II) Silicon Motionlg: Using hsync range of 14.00-80.00 kHz
>>> > (II) Silicon Motionlg: Using vrefresh range of 56.00-76.00 Hz
>>> > (II) Silicon MotionClock range:  14.00 to 135.00 MHz
>>> > (II) Silicon MotionMode: 640x480 16-bpp, 59.990181Hz
>>> > (II) Silicon MotionNot using mode "640x480i" (vrefresh out of range)
>>> > (II) Silicon MotionMode: 640x350 16-bpp, 85.079948Hz
>>> > (II) Silicon MotionNot using default mode "640x350" (vrefresh out of
>>> range)
>>> >
>>> >
>>> > vrefresh range is 56-76Hz, so why is my 640x480i modeline, at 59.99Hz
>>> > vrefresh, rejected ?
>>> >
>>> > the modeline is as follows:
>>> >
>>> >  ModeLine "640x480i" 24.44 640 680 728 776 480 480 484 525 Interlace
>>> > Composite
>>> >
>>> >
>>> >
>>> > bruno
>>> >
>>> >
>>> > On Wed, 7 Mar 2007, bruno schwander wrote:
>>> >
>>> >> I think I figured it out, however it seems that although my modeline
>>> >> includes 'composite'
>>> >>
>>> >> DisplayModePtr mode->Flags & V_CSYNC
>>> >>
>>> >> does not evaluate to true. I assume as long as the 'composite' keyword
>>> is
>>> >> found on the modeline, the flag should be set, right ?
>>> >>
>>> >> I need to add some debug messages, but this seems a little strange. Is
>>> >> there something else that needs to be configured, like telling that the
>>> >> driver actually supports the composite keyword on the modeline ?
>>> >>
>>> >> On a different note, the latest X release does not seem to work on that
>>> >> chip. I just get a blank screen. So I started hacking on Xorg 6.8.2 to
>>> test
>>> >> this stuff. I figure XFree86 4.5 should work, but 4.6 does not.
>>> >>
>>> >> I'll provide patches to all and note on which version it was tested of
>>> >> course, once it works :-)
>>> >>
>>> >> bruno
>>> >>
>>> >> On Tue, 27 Feb 2007, Marc Aurele La France wrote:
>>> >>
>>> >>> On Sun, 25 Feb 2007, bruno schwander wrote:
>>> >>>> On Fri, 23 Feb 2007, Marc Aurele La France wrote:
>

Re: siliconmotion CSync output ?

[Alex Deucher]

On 3/9/07, bruno schwander <[EMAIL PROTECTED]> wrote:

On Fri, 9 Mar 2007, Alex Deucher wrote:

> On 3/9/07, bruno schwander <[EMAIL PROTECTED]> wrote:
>> so I gather now that actually I should leave the xf86SetCrtcForModes()
>> alone, and just add setting the clock with CCR6C, CCR6D (and enabling it
>> with CCR68). I'll see how that goes...
>>
>
> exactly.  Sorry for not responding earlier.  You can use the
> SMI_CalcClock() function to calculate SR6C and SR6D, just like the
> mclk is generated. Use mode->Clock.  I have a similar patch in my xorg
> smi tree.

which xorg version are you up to, that has that patch ? did you mean it is
not comitted yet ? I can't get the latest either xfree86 or xorg to work
at all on that board I have with the smi712. I am testing currently with
xorg 6.8.2 because that is the one that still works. I will test and fold
in xfree86 4.5 but so far 4.6 does not work for me either.



The latest version of the siliconmotion driver in xorg git head should
have the lockup fix you need.  The problem is the engine doesn't need
to be synced until it has been started.  I've also added dualhead
support.  I haven't yet pushed the pll fix, that's still in my local
tree at home along with some other stuff I'm working on.  I can send
you a patch later if you want.

Alex


bruno

>
> Alex
>
>>
>> bruno
>>
>> On Thu, 8 Mar 2007, bruno schwander wrote:
>>
>> > On Thu, 8 Mar 2007, Alex Deucher wrote:
>> >
>> >> The siliconmotion driver doesn't explicitly set the vclk pll.  It uses
>> >> the bios (if UseBIOS is set or does nothing if not).
>> >
>> >
>> > that is what I was wondering...
>> > well, if I do not
>> >
>> > Options UseBIOS  false
>> >
>> > all I get is a blank screen. So I have to disable it. I did not realize
>> that
>> > it did not set the pixel clock since when using a default VGA 640x480
>> > resolution, it was working. So I guess it just happens to stay at
>> whatever
>> > pixel clock the BIOS or console driver had set it to ? That seems very
>> > strange.
>> >
>> >> It's trivial to add however. SR6C, SR6D are programmed similarly to the
>> >> mclk.
>> >
>> > I saw that mclk/dac stuff, yes, and was wondering how the pixel clock was
>> > really set. All this makes more sense now.
>> >
>> > So what you are saying is that in smi_driver.c : SMI_PreInit(), I should
>> > replace the call to xf86SetCrtcForModes(pScrn, 0), with an alternative
>> that
>> > programs vclk explicitely ?
>> >
>> > How can it set the crtc for several modes ? That is what
>> > xf86SetCrtcForModes() seems to do, right ?
>> >
>> > I still have a lot to learn.
>> >
>> > thanks for all the help guys, trudging along...
>> >
>> > bruno
>> >
>> >
>> >
>> >> Alex
>> >>
>> >>> Bruno
>> >>>
>> >>> On Wed, 7 Mar 2007, bruno schwander wrote:
>> >>>
>> >>> > ah actually now it is not choosing my modeline and I do not
>> understand
>> >>> why:
>> >>> >
>> >>> > (II) Silicon Motionlg: Using hsync range of 14.00-80.00 kHz
>> >>> > (II) Silicon Motionlg: Using vrefresh range of 56.00-76.00 Hz
>> >>> > (II) Silicon MotionClock range:  14.00 to 135.00 MHz
>> >>> > (II) Silicon MotionMode: 640x480 16-bpp, 59.990181Hz
>> >>> > (II) Silicon MotionNot using mode "640x480i" (vrefresh out of range)
>> >>> > (II) Silicon MotionMode: 640x350 16-bpp, 85.079948Hz
>> >>> > (II) Silicon MotionNot using default mode "640x350" (vrefresh out of
>> >>> range)
>> >>> >
>> >>> >
>> >>> > vrefresh range is 56-76Hz, so why is my 640x480i modeline, at 59.99Hz
>> >>> > vrefresh, rejected ?
>> >>> >
>> >>> > the modeline is as follows:
>> >>> >
>> >>> >  ModeLine "640x480i" 24.44 640 680 728 776 480 480 484 525 Interlace
>> >>> > Composite
>> >>> >
>> >>> >
>> >>> >
>> >>> > bruno
>> >>> >
>> >>> >
>> >>> > On Wed, 7 Mar 2007, bruno schwander wrote:
>> >>> >
>> >>> >> I think I figured it out, however it seems t

Re: siliconmotion CSync output ?

[Alex Deucher]

On 3/9/07, bruno schwander <[EMAIL PROTECTED]> wrote:

On Fri, 9 Mar 2007, Alex Deucher wrote:

> The latest version of the siliconmotion driver in xorg git head should
> have the lockup fix you need.  The problem is the engine doesn't need
> to be synced until it has been started.  I've also added dualhead
> support.  I haven't yet pushed the pll fix, that's still in my local
> tree at home along with some other stuff I'm working on.  I can send
> you a patch later if you want.

that would be awesome, yes ! so far what I added (enabling in CCR68
vclock scaled from CCR6C and CCR6D) crashes my pc... I used
SMI_CommonCalcClock() but I get wrong values back for the register values.
I am certainly not calling it right.


I just put my local tree up here:
http://gitweb.freedesktop.org/?p=users/agd5f/xf86-video-siliconmotion.git;a=summary
The relevant commit is a328d4378c28b788acf320bee9fbdfd129e0923d

I haven't tested any of this new code yet, so YMMV.  I haven't had
time this week and I need to rebuild my laptop with the smi chip, but
I hope to do that this weekend, at which point I should be able to
sort out any bugs.  Let me know if you haven any questions.

Alex




bruno


___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: siliconmotion CSync output ?

[Alex Deucher]

On 3/10/07, bruno schwander <[EMAIL PROTECTED]> wrote:

I looked at that diff and it looks like what I added, except that I also
set bits 7:6 of CCR68 to 01 because the doc I have says that will select
VCLK from the programmable VCLK regs, CCR6C and CCR6D.


Right, I should probably do that explicitly, although IIRC, the bios
does that during post.

Alex



I'll get "git" and give your tree a try, thanks

bruno


___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: siliconmotion CSync output ?

[Alex Deucher]

On 3/10/07, bruno schwander <[EMAIL PROTECTED]> wrote:

in SMI_Save(), SR6C and SR6D (and SR68) are saved only if pSmi->Dualhead,
why ? seems it should always be done ?


It should.  Like I said this is still my untested local working tree.
I'm aiming to add xrandr 1.2 support as well.



in SMI_WriteMode, those 2 are written twice, once everytime + once if
pSmi->Dualhead


see above :)



What's your take about CCR68 (SR68), also written only in dualhead
mode... seems if SR6C/SR6D are to be active, SR68 has to be configured
too.



yup.

Alex


bruno


___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: siliconmotion CSync output ?

[Alex Deucher]

On 3/10/07, bruno schwander <[EMAIL PROTECTED]> wrote:

I looked at that diff and it looks like what I added, except that I also
set bits 7:6 of CCR68 to 01 because the doc I have says that will select
VCLK from the programmable VCLK regs, CCR6C and CCR6D.



I fixed the vclk problem.  The postscalar shift was wrong in
SMI_CalcClocks().  either grab my updated tree or change the shift
from 6 to 7.

Alex
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: siliconmotion CSync output ?

[Alex Deucher]

On 3/12/07, bruno schwander <[EMAIL PROTECTED]> wrote:

I used your vclk setting code as in smi_driver.c, and changed the shift
in SMI_CommonCalcClock() but it seems to still have some
issue.

12220 clock gives me values of

SR6C: 63, SR6D: 1D



That's going to give you a vclk of ~48.88 Mhz

Unfortunately, the min clock on the smi is 20 Mhz (although I'd think
you should be able to get down to at least the reference clock), so
that may be causing a problem in the calculation function.  If you
want to calculate the clock yourself you can use the following
formula:

VCLK = 14.31818 Mhz * (VNR/VDR) * (1/(1 + PS))

VNR being SR6C and VDR and SR6D.  PS is bit 7 of SR6D.

I hope this helps.

Alex


bruno


On Sun, 11 Mar 2007, Alex Deucher wrote:

> On 3/10/07, bruno schwander <[EMAIL PROTECTED]> wrote:
>> I looked at that diff and it looks like what I added, except that I also
>> set bits 7:6 of CCR68 to 01 because the doc I have says that will select
>> VCLK from the programmable VCLK regs, CCR6C and CCR6D.
>>
>
> I fixed the vclk problem.  The postscalar shift was wrong in
> SMI_CalcClocks().  either grab my updated tree or change the shift
> from 6 to 7.
>
> Alex

___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: siliconmotion CSync output ?

[Alex Deucher]

On 3/13/07, bruno schwander <[EMAIL PROTECTED]> wrote:

On Mon, 12 Mar 2007, Alex Deucher wrote:

> On 3/12/07, bruno schwander <[EMAIL PROTECTED]> wrote:
>> I used your vclk setting code as in smi_driver.c, and changed the shift
>> in SMI_CommonCalcClock() but it seems to still have some
>> issue.
>>
>> 12220 clock gives me values of
>>
>> SR6C: 63, SR6D: 1D
>>
>
> That's going to give you a vclk of ~48.88 Mhz

yeah, I know.

I meant that SMI_CommonCalcClock should have come up with different
values, instead it returned the values above.

> Unfortunately, the min clock on the smi is 20 Mhz (although I'd think

hmm that would be really annoying...where do you get that ? I can't find


that's just what was specified in the driver originally.  smi wrote it...


any mention of such a limitation. Just the hope that given the right
SR6C/D values, I can get any corresponding dot clock :-)



try bumping the max n1 up.  see my newest code below.


I did chnge the minclock values so that it accepts lower clock requests,
but I have not checked it it actually generates those frequencies. Need
the scope...



Good luck!  let me know how it goes.


> you should be able to get down to at least the reference clock), so
> that may be causing a problem in the calculation function.  If you
> want to calculate the clock yourself you can use the following
> formula:
>
> VCLK = 14.31818 Mhz * (VNR/VDR) * (1/(1 + PS))
>
> VNR being SR6C and VDR and SR6D.  PS is bit 7 of SR6D.

the spec I have for the smi712 (lynxEM+) says bit 7 and 6 are PS,
as follows:

bit 6  bit 7  vclk
0  0  PS not enabled, programmed vclk
0  1  PS enabled, vclk = 1/2 programmed vclk
1  0  PS enabled, vclk = 1/4 prog vlck
1  1  PS enabled, vclk = 1/8 prog vlck


Ah, I was reading the 722 book.  I didn't realize the 712 had 2 bits
for PS; you might have more luck in that case.  I fixed up the driver
to deal with this and set the proper min/max values for the
calculation.
http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-siliconmotion.git;a=summary

Alex




bruno

___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: patches for Darwin /MacOSX

[Alex Deucher]

On 4/6/07, SciFi <[EMAIL PROTECTED]> wrote:


Yves' changes did not help getting stuck several times during the
build here.  I'll be documenting as best I can and send 'em thru
bugzilla.  I bet we'll be too late for Apple to put this into
Leopard, I have no idea what they're doing since I can't afford a
$pay-for$ ADC account there or get a 'sponsor'.  :(



Apple has people actively working on Xorg.  Most of their recent
changes have been already been pushed or are pending on branches.

Alex
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: patches for Darwin /MacOSX

[Alex Deucher]

On 4/11/07, SciFi <[EMAIL PROTECTED]> wrote:

On Fri 06 Apr 2007 14:01:59 -0400,
Alex Deucher wrote:
> On 4/6/07, SciFi <[EMAIL PROTECTED]> wrote:
>>
>> Yves' changes did not help getting stuck several times during
>> the build here.  I'll be documenting as best I can and send
>> 'em thru bugzilla.  I bet we'll be too late for Apple to put
>> this into Leopard, I have no idea what they're doing since I
>> can't afford a $pay-for$ ADC account there or get a
>> 'sponsor'.  :(
>
> Apple has people actively working on Xorg.  Most of their
> recent changes have been already been pushed or are pending on
> branches.
>
> Alex

Their present X11.app on Tiger shows XFree86, not Xorg.
Did they "switch" again???  I definitely remember a lot of
us sending feedback some years ago to have them switch *TO*
XFree86, which they did.  Good grief I'm gettin' dizzy...  ;)



Again?  I think they only switched once.  Tiger support was written a
while ago.  They have people working on Xorg support for the next
release or an update I assume.  You'd have to ask them what the plan
is.

Alex
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: X driver: Using offscreen memory manager for Xv

[Alex Deucher]

On Nov 26, 2007 8:08 PM, Bankim Bhavsar <[EMAIL PROTECTED]> wrote:
> I'm implementing Xv extension of linux X driver.
>
> I need to use offscreen memory to allocate space for incoming video-frames.
> Currently, I am using xf86InitFBManager() part of xf86fbman.h to
> initialize offscreen memory by specifying a BoxPtr. The offscreen
> memory is initialized such that it starts just after the on-screen
> memory (using Frame Buffer Size).
>
>
> When there is a ModeSwitch the Frame Buffer Size changes and the
> offscreen memory previously allocated becomes a part of the on-screen
> memory and causes X to crash. I was thinking of re-initalizing the
> Offscreen memory manager on ModeSwitch and modify the previously
> allocated pointers accordingly but I don't see a way to re-initialize
> the offscreen memory.
>
>
> One possible solution would be to leave some space before starting the
> offscreen memory. That would work for common case but still doesn't
> guarantee the framebuffer extending into the previously initialized
> offscreen memory.
>
>
> I also looked into EXA but doesn't seem to serve the purpose either.
>
>
> Am I missing out on something? Any other possible solution?
> Can someone point me to a driver that uses EXA and handles the offscreen
> memory on ModeSwitch?

I believe nv does this.

Alex
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: xaa vs. WriteImage()

[Alex Deucher]

On Tue, Mar 4, 2008 at 5:34 PM, Michael Lorenz <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
>  Hash: SHA1
>
>  Hello,
>
>
> On Mar 4, 2008, at 15:37, Marc Aurele La France wrote:
>
>  > On Mon, 3 Mar 2008, Michael Lorenz wrote:
>  >
>  >> I noticed the following - XAACopyArea() only attempts to use
>  >> accelerated WriteImage() when writing to a DRAWABLE_WINDOW but not
>  >> on off-screen pixmaps. I used the following changes to make it work:
>  >
>  >> diff -u -w -r1.1.1.3 xaaCpyArea.c
>  >> - --- xaaCpyArea.c   9 Jun 2001 15:09:02 -   1.1.1.3
>  >> +++ xaaCpyArea.c 3 Mar 2008 20:51:05 -
>  >> @@ -64,9 +64,16 @@
>  >>return (XAABitBlt( pSrcDrawable, pDstDrawable,
>  >>  pGC, srcx, srcy, width, height, dstx, dsty,
>  >>  XAADoBitBlt, 0L));
>  >> +} else {
>  >> +if(infoRec->ScreenToScreenBitBlt &&
>  >> + CHECK_ROP(pGC,infoRec->ScreenToScreenBitBltFlags) &&
>  >> + CHECK_ROPSRC(pGC,infoRec->ScreenToScreenBitBltFlags) &&
>  >> + CHECK_PLANEMASK(pGC,infoRec->ScreenToScreenBitBltFlags))
>  >> +return (XAABitBlt( pSrcDrawable, pDstDrawable,
>  >> +pGC, srcx, srcy, width, height, dstx, dsty,
>  >> +XAADoImageWrite, 0L));
>  >>  }
>  >>}
>  >
>  > This does not look correct.  Shouldn't this be more in line with
>  > the case where the destination drawable is a window?  (i.e. test
>  > bitsPerPixel's and WritePixmap files instead of ScreenToScreenBitBlt).
>
>  The whole logic looks a little bit fishy, I used the first if()'s
>  source-in-memory branch first but wasn't quite sure if that's doing
>  the right thing, where it;s now looked better to me but I won't claim
>  I completely understand XAA's inner voodoo. All I want is the make
>  XAA use ImageWrite()s for all RAM-to-VRAM transfers if the driver
>  supports it.
>  Otherwise, teaching the framebuffer layer to cope with a tiled
>  framebuffer might be necessary in the long run, any pointers where to
>  start?

Several drivers (radeon, intel, savage) in the Xorg tree provide
support for various tiling methods.  Generally the chip provides a
surface control or aperture for exposing a tiled region to the CPU as
a linear surface.  For acceleration, you have to keep track of what
buffers are tiled in the driver and do the right thing with the
blitter when using those surfaces.

Alex
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: xaa vs. WriteImage()

[Alex Deucher]

On Thu, Mar 6, 2008 at 2:00 PM, Michael Lorenz <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
>  Hash: SHA1
>
>  Hello,
>
>  On Mar 5, 2008, at 19:06, Alex Deucher wrote:
>
>  > On Tue, Mar 4, 2008 at 5:34 PM, Michael Lorenz
>  > <[EMAIL PROTECTED]> wrote:
>  >> -BEGIN PGP SIGNED MESSAGE-
>  >>  Hash: SHA1
>  >>
>  >>  Hello,
>  >>
>  >>
>  >> On Mar 4, 2008, at 15:37, Marc Aurele La France wrote:
>  >>
>  >>> On Mon, 3 Mar 2008, Michael Lorenz wrote:
>  >>>
>  >>>> I noticed the following - XAACopyArea() only attempts to use
>  >>>> accelerated WriteImage() when writing to a DRAWABLE_WINDOW but not
>  >>>> on off-screen pixmaps. I used the following changes to make it
>  >>>> work:
>  >>>
>  >>>> diff -u -w -r1.1.1.3 xaaCpyArea.c
>  >>>> - --- xaaCpyArea.c   9 Jun 2001 15:09:02 -   1.1.1.3
>  >>>> +++ xaaCpyArea.c 3 Mar 2008 20:51:05 -
>  >>>> @@ -64,9 +64,16 @@
>  >>>>return (XAABitBlt( pSrcDrawable, pDstDrawable,
>  >>>>  pGC, srcx, srcy, width, height, dstx, dsty,
>  >>>>  XAADoBitBlt, 0L));
>  >>>> +} else {
>  >>>> +if(infoRec->ScreenToScreenBitBlt &&
>  >>>> + CHECK_ROP(pGC,infoRec->ScreenToScreenBitBltFlags) &&
>  >>>> + CHECK_ROPSRC(pGC,infoRec->ScreenToScreenBitBltFlags) &&
>  >>>> + CHECK_PLANEMASK(pGC,infoRec->ScreenToScreenBitBltFlags))
>  >>>> +return (XAABitBlt( pSrcDrawable, pDstDrawable,
>  >>>> +pGC, srcx, srcy, width, height, dstx, dsty,
>  >>>> +XAADoImageWrite, 0L));
>  >>>>  }
>  >>>>}
>  >>>
>  >>> This does not look correct.  Shouldn't this be more in line with
>  >>> the case where the destination drawable is a window?  (i.e. test
>  >>> bitsPerPixel's and WritePixmap files instead of
>  >>> ScreenToScreenBitBlt).
>  >>
>  >>  The whole logic looks a little bit fishy, I used the first if()'s
>  >>  source-in-memory branch first but wasn't quite sure if that's doing
>  >>  the right thing, where it;s now looked better to me but I won't
>  >> claim
>  >>  I completely understand XAA's inner voodoo. All I want is the make
>  >>  XAA use ImageWrite()s for all RAM-to-VRAM transfers if the driver
>  >>  supports it.
>  >>  Otherwise, teaching the framebuffer layer to cope with a tiled
>  >>  framebuffer might be necessary in the long run, any pointers
>  >> where to
>  >>  start?
>  >
>  > Several drivers (radeon, intel, savage) in the Xorg tree provide
>  > support for various tiling methods.  Generally the chip provides a
>  > surface control or aperture for exposing a tiled region to the CPU as
>  > a linear surface.  For acceleration, you have to keep track of what
>  > buffers are tiled in the driver and do the right thing with the
>  > blitter when using those surfaces.
>
>  Yeah, I'm dimly aware of these things - my problem is that the
>  hardware in question doesn't give me a linear view on the framebuffer.
>  All I have is a small linear buffer I can use to DMA data in or out
>  of the tiled framebuffer. The other problem is that the machine's
>  native pixel format is RGBA, if I want 24bit colour that's the only
>  one I can use. Fortunately the DMA engine can convert pixels on the
>  fly so I can pretend it's ABGR. So pixels would have to be endian-
>  flipped as well when the fb layer accesses VRAM - is there any prior
>  art for that?

EXA has prepare/finish access hooks for CPU access to buffers.  I
don't think XAA has anything similar.  There's also an wrapable FB
module, although I think it's only available in Xorg.

Alex

>  So far my driver supports image writes, screen-to-screen copies,
>  rectangle fills, solid and dashed lines, colour expansion and alpha
>  textures. ARGB textures should work as well but I couldn't find a
>  user for those - nothing in xfce4 or windowmaker seems to do anything
>  with that.
>  Another thing - I sprinkled xf86Msg()s all over XAA, sometimes
>  XCopyArea() calls seem to end up writing to the framebuffer but not
>  through xaaCopyArea() - any ideas?

Sorry, I'm not that familiar with XAA.

Alex

>
>  have fun
>  Michael
>  -BEGIN PGP SIGNATURE-
>  Version: GnuPG v1.4.7 (Darwin)
>
>  iQEVAwUBR89I6cpnzkX8Yg2nAQIkHAgAribd+WTw/t5Xv5nunNUZn6hrwluv+e7J
>  ox9Hg9V/Yp2CVZVPgSc+3aJOjLPUTPg6L/4tVuNBQLSVnbMO2j7MdGLkhxGznGzl
>  iv5NNqqToXDO2MM9ctBo8dNB1o3RU76dnbs4QomHYqi/HpNmG+JLJLu3L1+uNjoC
>  cKjTsUEKWM/UgK+A2UMkjV9vpdEEYoYz2zRu6Njy3bfP7Jyoyh7mwl/c/kamWvU6
>  k8KnHcRalgsXjmhNRGSV4VOmpc3c/JubHROYTrG5T61aNVge1GAi2jLl27I99vhR
>  0Bv8iA6juJ5KxZpUajbHSL5vXAZk/QaXss1g7AuVSGCphqE3IC/kHA==
>  =wynV
>  -END PGP SIGNATURE-
>  ___
>  Devel mailing list
>  Devel@XFree86.Org
>  http://XFree86.Org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: xaa vs. WriteImage()

[Alex Deucher]

On Thu, Mar 6, 2008 at 2:58 PM, Michael Lorenz <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
>  Hash: SHA1
>
>  Hello,
>
>  On Mar 6, 2008, at 14:12, Alex Deucher wrote:
>
>  > On Thu, Mar 6, 2008 at 2:00 PM, Michael Lorenz
>  > <[EMAIL PROTECTED]> wrote:
>  >> -BEGIN PGP SIGNED MESSAGE-
>  >>  Hash: SHA1
>  >>
>  >>  Hello,
>  >>
>  >>  On Mar 5, 2008, at 19:06, Alex Deucher wrote:
>  >>
>  >>> On Tue, Mar 4, 2008 at 5:34 PM, Michael Lorenz
>  >>> <[EMAIL PROTECTED]> wrote:
>  >>>> -BEGIN PGP SIGNED MESSAGE-
>  >>>>  Hash: SHA1
>  >>>>
>  >>>>  Hello,
>  >>>>
>  >>>>
>  >>>> On Mar 4, 2008, at 15:37, Marc Aurele La France wrote:
>  >>>>
>  >>>>> On Mon, 3 Mar 2008, Michael Lorenz wrote:
>  >>>>>
>  >>>>>> I noticed the following - XAACopyArea() only attempts to use
>  >>>>>> accelerated WriteImage() when writing to a DRAWABLE_WINDOW but
>  >>>>>> not
>  >>>>>> on off-screen pixmaps. I used the following changes to make it
>  >>>>>> work:
>  >>>>>
>  >>>>>> diff -u -w -r1.1.1.3 xaaCpyArea.c
>  >>>>>> - --- xaaCpyArea.c   9 Jun 2001 15:09:02 -   1.1.1.3
>  >>>>>> +++ xaaCpyArea.c 3 Mar 2008 20:51:05 -
>  >>>>>> @@ -64,9 +64,16 @@
>  >>>>>>return (XAABitBlt( pSrcDrawable, pDstDrawable,
>  >>>>>>  pGC, srcx, srcy, width, height, dstx, dsty,
>  >>>>>>  XAADoBitBlt, 0L));
>  >>>>>> +} else {
>  >>>>>> +if(infoRec->ScreenToScreenBitBlt &&
>  >>>>>> + CHECK_ROP(pGC,infoRec->ScreenToScreenBitBltFlags) &&
>  >>>>>> + CHECK_ROPSRC(pGC,infoRec->ScreenToScreenBitBltFlags) &&
>  >>>>>> + CHECK_PLANEMASK(pGC,infoRec-
>  >>>>>> >ScreenToScreenBitBltFlags))
>  >>>>>> +return (XAABitBlt( pSrcDrawable, pDstDrawable,
>  >>>>>> +pGC, srcx, srcy, width, height, dstx, dsty,
>  >>>>>> +XAADoImageWrite, 0L));
>  >>>>>>  }
>  >>>>>>}
>  >>>>>
>  >>>>> This does not look correct.  Shouldn't this be more in line with
>  >>>>> the case where the destination drawable is a window?  (i.e. test
>  >>>>> bitsPerPixel's and WritePixmap files instead of
>  >>>>> ScreenToScreenBitBlt).
>  >>>>
>  >>>>  The whole logic looks a little bit fishy, I used the first if()'s
>  >>>>  source-in-memory branch first but wasn't quite sure if that's
>  >>>> doing
>  >>>>  the right thing, where it;s now looked better to me but I won't
>  >>>> claim
>  >>>>  I completely understand XAA's inner voodoo. All I want is the make
>  >>>>  XAA use ImageWrite()s for all RAM-to-VRAM transfers if the driver
>  >>>>  supports it.
>  >>>>  Otherwise, teaching the framebuffer layer to cope with a tiled
>  >>>>  framebuffer might be necessary in the long run, any pointers
>  >>>> where to
>  >>>>  start?
>  >>>
>  >>> Several drivers (radeon, intel, savage) in the Xorg tree provide
>  >>> support for various tiling methods.  Generally the chip provides a
>  >>> surface control or aperture for exposing a tiled region to the
>  >>> CPU as
>  >>> a linear surface.  For acceleration, you have to keep track of what
>  >>> buffers are tiled in the driver and do the right thing with the
>  >>> blitter when using those surfaces.
>  >>
>  >>  Yeah, I'm dimly aware of these things - my problem is that the
>  >>  hardware in question doesn't give me a linear view on the
>  >> framebuffer.
>  >>  All I have is a small linear buffer I can use to DMA data in or out
>  >>  of the tiled framebuffer. The other problem is that the machine's
>  >>  native pixel format is RGBA, if I want 24bit colour that's the only
>  >>  one I can use. Fortunately the DMA engine can convert pixels on the
>  >>  fly so I can pretend it's ABGR. So pixels would have to be endian-
>  >>  flipped as well when the fb layer accesses VRAM - is there any prior
>  >>  art for that?
>  >
>  > EXA has prepare/finish access hooks for CPU access to buffers.  I
>  > don't think XAA has anything similar.  There's also an wrapable FB
>  > module, although I think it's only available in Xorg.
>
>  I'll have a look at that - the main reason I'm using XFree86 is that
>  it's already working on NetBSD/sgimips, Xorg needs some more work but
>  I'll eventually do it.
>  Hmm, some drivers access video memory through tiny apertures like the
>  VGA range - maybe I can do something like this - let the rest of the
>  Xserver render into my DMA buffer and then blit it in place.

Use shadowfb and hook in a custom shadowupdate() function.

Alex
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: xaa vs. WriteImage()

[Alex Deucher]

On Thu, Mar 6, 2008 at 2:58 PM, Michael Lorenz <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
>  Hash: SHA1
>
>  Hello,
>
>  On Mar 6, 2008, at 14:12, Alex Deucher wrote:
>
>  > On Thu, Mar 6, 2008 at 2:00 PM, Michael Lorenz
>  > <[EMAIL PROTECTED]> wrote:
>  >> -BEGIN PGP SIGNED MESSAGE-
>  >>  Hash: SHA1
>  >>
>  >>  Hello,
>  >>
>  >>  On Mar 5, 2008, at 19:06, Alex Deucher wrote:
>  >>
>  >>> On Tue, Mar 4, 2008 at 5:34 PM, Michael Lorenz
>  >>> <[EMAIL PROTECTED]> wrote:
>  >>>> -BEGIN PGP SIGNED MESSAGE-
>  >>>>  Hash: SHA1
>  >>>>
>  >>>>  Hello,
>  >>>>
>  >>>>
>  >>>> On Mar 4, 2008, at 15:37, Marc Aurele La France wrote:
>  >>>>
>  >>>>> On Mon, 3 Mar 2008, Michael Lorenz wrote:
>  >>>>>
>  >>>>>> I noticed the following - XAACopyArea() only attempts to use
>  >>>>>> accelerated WriteImage() when writing to a DRAWABLE_WINDOW but
>  >>>>>> not
>  >>>>>> on off-screen pixmaps. I used the following changes to make it
>  >>>>>> work:
>  >>>>>
>  >>>>>> diff -u -w -r1.1.1.3 xaaCpyArea.c
>  >>>>>> - --- xaaCpyArea.c   9 Jun 2001 15:09:02 -   1.1.1.3
>  >>>>>> +++ xaaCpyArea.c 3 Mar 2008 20:51:05 -
>  >>>>>> @@ -64,9 +64,16 @@
>  >>>>>>return (XAABitBlt( pSrcDrawable, pDstDrawable,
>  >>>>>>  pGC, srcx, srcy, width, height, dstx, dsty,
>  >>>>>>  XAADoBitBlt, 0L));
>  >>>>>> +} else {
>  >>>>>> +if(infoRec->ScreenToScreenBitBlt &&
>  >>>>>> + CHECK_ROP(pGC,infoRec->ScreenToScreenBitBltFlags) &&
>  >>>>>> + CHECK_ROPSRC(pGC,infoRec->ScreenToScreenBitBltFlags) &&
>  >>>>>> + CHECK_PLANEMASK(pGC,infoRec-
>  >>>>>> >ScreenToScreenBitBltFlags))
>  >>>>>> +return (XAABitBlt( pSrcDrawable, pDstDrawable,
>  >>>>>> +pGC, srcx, srcy, width, height, dstx, dsty,
>  >>>>>> +XAADoImageWrite, 0L));
>  >>>>>>  }
>  >>>>>>}
>  >>>>>
>  >>>>> This does not look correct.  Shouldn't this be more in line with
>  >>>>> the case where the destination drawable is a window?  (i.e. test
>  >>>>> bitsPerPixel's and WritePixmap files instead of
>  >>>>> ScreenToScreenBitBlt).
>  >>>>
>  >>>>  The whole logic looks a little bit fishy, I used the first if()'s
>  >>>>  source-in-memory branch first but wasn't quite sure if that's
>  >>>> doing
>  >>>>  the right thing, where it;s now looked better to me but I won't
>  >>>> claim
>  >>>>  I completely understand XAA's inner voodoo. All I want is the make
>  >>>>  XAA use ImageWrite()s for all RAM-to-VRAM transfers if the driver
>  >>>>  supports it.
>  >>>>  Otherwise, teaching the framebuffer layer to cope with a tiled
>  >>>>  framebuffer might be necessary in the long run, any pointers
>  >>>> where to
>  >>>>  start?
>  >>>
>  >>> Several drivers (radeon, intel, savage) in the Xorg tree provide
>  >>> support for various tiling methods.  Generally the chip provides a
>  >>> surface control or aperture for exposing a tiled region to the
>  >>> CPU as
>  >>> a linear surface.  For acceleration, you have to keep track of what
>  >>> buffers are tiled in the driver and do the right thing with the
>  >>> blitter when using those surfaces.
>  >>
>  >>  Yeah, I'm dimly aware of these things - my problem is that the
>  >>  hardware in question doesn't give me a linear view on the
>  >> framebuffer.
>  >>  All I have is a small linear buffer I can use to DMA data in or out
>  >>  of the tiled framebuffer. The other problem is that the machine's
>  >>  native pixel format is RGBA, if I want 24bit colour that's the only
>  >>  one I can use. Fortunately the DMA engine can convert pixels on the
>  >>  fly so I can pretend it's ABGR. So pixels would have to be endian-
>  >>  flipped as well when the fb layer accesses VRAM - is there any prior
>  >>  art for that?
>  >
>  > EXA has prepare/finish access hooks for CPU access to buffers.  I
>  > don't think XAA has anything similar.  There's also an wrapable FB
>  > module, although I think it's only available in Xorg.
>
>  I'll have a look at that - the main reason I'm using XFree86 is that
>  it's already working on NetBSD/sgimips, Xorg needs some more work but
>  I'll eventually do it.
>  Hmm, some drivers access video memory through tiny apertures like the
>  VGA range - maybe I can do something like this - let the rest of the
>  Xserver render into my DMA buffer and then blit it in place.

The sgi impact driver does something similar:
http://cgit.freedesktop.org/xorg/driver/xf86-video-impact/

Alex
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: xaa vs. WriteImage()

[Alex Deucher]

On Thu, Mar 6, 2008 at 4:26 PM, Michael Lorenz <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
>  Hash: SHA1
>
>  Hello,
>
>
>
> On Mar 6, 2008, at 15:58, Alex Deucher wrote:
>
>  > On Thu, Mar 6, 2008 at 2:58 PM, Michael Lorenz
>  > <[EMAIL PROTECTED]> wrote:
>  >> -BEGIN PGP SIGNED MESSAGE-
>  >>  Hash: SHA1
>  >>
>  >>  Hello,
>  >>
>  >>  On Mar 6, 2008, at 14:12, Alex Deucher wrote:
>  >>
>  >>> On Thu, Mar 6, 2008 at 2:00 PM, Michael Lorenz
>  >>> <[EMAIL PROTECTED]> wrote:
>  >>>> -BEGIN PGP SIGNED MESSAGE-
>  >>>>  Hash: SHA1
>  >>>>
>  >>>>  Hello,
>  >>>>
>  >>>>  On Mar 5, 2008, at 19:06, Alex Deucher wrote:
>  >>>>
>  >>>>> On Tue, Mar 4, 2008 at 5:34 PM, Michael Lorenz
>  >>>>> <[EMAIL PROTECTED]> wrote:
>  >>>>>> -BEGIN PGP SIGNED MESSAGE-
>  >>>>>>  Hash: SHA1
>  >>>>>>
>  >>>>>>  Hello,
>  >>>>>>
>  >>>>>>
>  >>>>>> On Mar 4, 2008, at 15:37, Marc Aurele La France wrote:
>  >>>>>>
>  >>>>>>> On Mon, 3 Mar 2008, Michael Lorenz wrote:
>  >>>>>>>
>  >>>>>>>> I noticed the following - XAACopyArea() only attempts to use
>  >>>>>>>> accelerated WriteImage() when writing to a DRAWABLE_WINDOW but
>  >>>>>>>> not
>  >>>>>>>> on off-screen pixmaps. I used the following changes to make it
>  >>>>>>>> work:
>  >>>>>>>
>  >>>>>>>> diff -u -w -r1.1.1.3 xaaCpyArea.c
>  >>>>>>>> - --- xaaCpyArea.c   9 Jun 2001 15:09:02 -   1.1.1.3
>  >>>>>>>> +++ xaaCpyArea.c 3 Mar 2008 20:51:05 -
>  >>>>>>>> @@ -64,9 +64,16 @@
>  >>>>>>>>return (XAABitBlt( pSrcDrawable, pDstDrawable,
>  >>>>>>>>  pGC, srcx, srcy, width, height, dstx, dsty,
>  >>>>>>>>  XAADoBitBlt, 0L));
>  >>>>>>>> +} else {
>  >>>>>>>> +if(infoRec->ScreenToScreenBitBlt &&
>  >>>>>>>> + CHECK_ROP(pGC,infoRec->ScreenToScreenBitBltFlags) &&
>  >>>>>>>> + CHECK_ROPSRC(pGC,infoRec-
>  >>>>>>>> >ScreenToScreenBitBltFlags) &&
>  >>>>>>>> + CHECK_PLANEMASK(pGC,infoRec-
>  >>>>>>>>> ScreenToScreenBitBltFlags))
>  >>>>>>>> +return (XAABitBlt( pSrcDrawable, pDstDrawable,
>  >>>>>>>> +pGC, srcx, srcy, width, height, dstx, dsty,
>  >>>>>>>> +XAADoImageWrite, 0L));
>  >>>>>>>>  }
>  >>>>>>>>}
>  >>>>>>>
>  >>>>>>> This does not look correct.  Shouldn't this be more in line with
>  >>>>>>> the case where the destination drawable is a window?  (i.e. test
>  >>>>>>> bitsPerPixel's and WritePixmap files instead of
>  >>>>>>> ScreenToScreenBitBlt).
>  >>>>>>
>  >>>>>>  The whole logic looks a little bit fishy, I used the first if
>  >>>>>> ()'s
>  >>>>>>  source-in-memory branch first but wasn't quite sure if that's
>  >>>>>> doing
>  >>>>>>  the right thing, where it;s now looked better to me but I won't
>  >>>>>> claim
>  >>>>>>  I completely understand XAA's inner voodoo. All I want is the
>  >>>>>> make
>  >>>>>>  XAA use ImageWrite()s for all RAM-to-VRAM transfers if the
>  >>>>>> driver
>  >>>>>>  supports it.
>  >>>>>>  Otherwise, teaching the framebuffer layer to cope with a tiled
>  >>>>>>  framebuffer might be necessary in the long run, any pointers
>  >>>>>> where to
>  >>>>>>  start?
>  >>>>>
>  >>>>> Several drivers (radeon, intel, savage) in the Xorg tree provide
>  >&g

Re: xaa vs. WriteImage()

[Alex Deucher]

On Thu, Mar 6, 2008 at 5:17 PM, Michael Lorenz <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
>  Hash: SHA1
>
>  Hello,
>
>  On Mar 6, 2008, at 16:40, Alex Deucher wrote:
>
>  > On Thu, Mar 6, 2008 at 4:26 PM, Michael Lorenz
>  > <[EMAIL PROTECTED]> wrote:
>  >> On Mar 6, 2008, at 15:58, Alex Deucher wrote:
>  >>
>  >>> On Thu, Mar 6, 2008 at 2:58 PM, Michael Lorenz
>  >>> <[EMAIL PROTECTED]> wrote:
>  >>>> -BEGIN PGP SIGNED MESSAGE-
>  >>>>  Hash: SHA1
>  >>>>
>  >>>>  Hello,
>  >>>>
>  >>>>  On Mar 6, 2008, at 14:12, Alex Deucher wrote:
>  >>>>
>  >>>>> On Thu, Mar 6, 2008 at 2:00 PM, Michael Lorenz
>  >>>>> EXA has prepare/finish access hooks for CPU access to buffers.  I
>  >>>>> don't think XAA has anything similar.  There's also an wrapable FB
>  >>>>> module, although I think it's only available in Xorg.
>  >>>>
>  >>>>  I'll have a look at that - the main reason I'm using XFree86 is
>  >>>> that
>  >>>>  it's already working on NetBSD/sgimips, Xorg needs some more work
>  >>>> but
>  >>>>  I'll eventually do it.
>  >>>>  Hmm, some drivers access video memory through tiny apertures like
>  >>>> the
>  >>>>  VGA range - maybe I can do something like this - let the rest
>  >>>> of the
>  >>>>  Xserver render into my DMA buffer and then blit it in place.
>  >>>
>  >>> Use shadowfb and hook in a custom shadowupdate() function.
>  >>
>  >>  Wouldn't that interfere with XAA? If I could catch the framebuffer
>  >>  writes that bypass XAA that way that would solve my problem.
>  >>  Thanks!
>  >
>  > Yeah, you gotta pick one or the other IIRC.  However for most modern
>  > desktops you either have to be entirely SW or entirely HW or
>  > performance sucks.  You lose if any sort of fallbacks cause a pixmap
>  > migration to/from vram.
>
>  In my case VRAM is RAM, and the CPU is pretty slow - I've had things
>  running entirely SW and performance sucked. Not the slowest I've ever
>  seen but nowhere near what the HW can do.
>  Also, many X applications have trouble with the HW's native pixel
>  format, cairo for instance just crashes. Using the DMA engine I can
>  pretend it's using something more common - ABGR - and those
>  applications just work fine. I think the next thing I'll try is to
>  pretend that we're accessing VRAM through a small window, there must
>  be prior art for that somewhere in the source tree.
>

the sgi impact driver I mentioned before
(http://cgit.freedesktop.org/xorg/driver/xf86-video-impact/) does
that.  IIRC, there's no way to access the vram directly so everything
gets sent to the card via dma.

Alex
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

question about shared Entities and multiple CRTCs

[Alex Deucher]

I'm trying to add duoview support (dual head -- 2 crtcs, one chip) to
the savage driver, but I keep getting "entity already in use" errors. 
I've studied the mga and radeon code thoroughly and I've read the
DESIGN guide, and I think I have a pretty good understanding of what
need to be done, but for the life of me, I can't figure out what I'm
missing; why the entity is not being marked as shared.  Does anyone
know of any good doc or other code I can read to get a better
understanding of shared entities (other than xfree86/common/*.c/h)? 
Also, I would appreciate if someone could look over my code and see if
there is any glaring mistake that would be causing this error.  Code is
available here:

http://www.botchco.com/alex/new-savage/savage/

I haven't messed with the acceleration code yet, so you'll need to run
it with "noaccel."  same goes for hw cursor.

Thanks,

Alex

__
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: RELNOTES for 4.3.0

[Alex Deucher]

I'm using 1.1.26, on my savage IX (IBM T20) and it works fine.  I'm
using it as the basis for the duoview support I'm adding.

Alex

--- "Mike A. Harris" <[EMAIL PROTECTED]> wrote:
> On 21 Feb 2003, Juliusz Chroboczek wrote:
> 
> >Oh, and what about the Savage changes?  XFree86 no longer crashes
> the
> >TwisterK, which is important for a lot of people.
> >
> >Unless Tim is around, here's my proposal:
> >
> >  Fixes Savage problems on the TwisterK, including hangs in the
> >  Blaster xscreensaver hack and hangs with XVideo.  Also fixes
> >  incorrect memory size detection.
> >
> >(There's probably more, but that's the ones that were biting me.)
> 
> The CVS XFree86 savage 1.1.26 driver is useless on Savage MX and
> Savage IX. The 'vesa' driver works on those 2 though.
> 
> I'm told it broke sometime in December.
> 
> 
> 
> -- 
> Mike A. Harris
> 
> 
> ___
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel


__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: Mouse Daemon for Linux/FreeBSD?

[Alex Deucher]

I believe Zephaniah E. Hull was doing some work for getting xfree86 to
work dynamically with the 2.5 input layer.  I think it was called
evdev.  I can't seem to find the link to his site at the moment though.

Alex


--- "Charl P. Botha" <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 28, 2003 at 10:54:17AM -0800, Kendall Bennett wrote:
> > So I am wondering what sort of interest there would be in a high
> quality 
> > mouse daemon for Linux that could handle all of the mouse
> communications 
> > for Linux programs. The idea would be that there would be a single
> mouse 
> > daemon in the system that runs in user space that auto-detects the 
> > installed mouse and provides event translation for all apps in the 
> > system, including XFree86.
> 
> Before you start churning out reams of code, please have a look at
> the new
> Linux kernel 2.5 input layer.  Drivers are at kernel level and are
> presented
> to userland via a generic event interface.
> 
> -- 
> charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/
> ___
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel


__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: patches: qnx neutrino (nto) 6.2, mb86291-scarlet, startup-speedup

[Alex Deucher]

Send your patches to [EMAIL PROTECTED] and/or [EMAIL PROTECTED] for
inclusion in a future release.

Alex

--- Sven Goethel <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> dear xfree developers,
> 
> i have added xfree86 _server_ support for 
> qnx neutrino 6.2 !
> 
> this includes a mit-shm layer on top of nto's posix-shm
> implementation,
> as well as the nto's pci access !
> 
> currently i do transfer my patches to the latest xfree86 4.3 cvs
> locally
> 
> so, if anybody is intresting in, how can i contribute my patches ?
> 
> +++
> 
> beneath the general nto support, i have done some special patches
> which does decrease the startup-time of the xserver as well.
> for example, a special pci-scan, which only scans the given pci
> bus/dev/func,
> instead of running through the whole ..
> this is intended to speed up xserver for embedded systems ..
> 
> i would like to contribute this too ..
> 
> +++
> 
> beneath this stuff, i have written an xserver driver module for 
> the fujitsu's MB86291 'Scarlet' gfx chip !
> 
> i would like to contribute this too ..
> 
> +++
> 
> this whole work is an ongoing project of Harman/Becker,
> to evaluate an open architecture for the display driver subset
> for automobile devices.
> 
> because the use of qnx, we had to port the xserver to this platform,
> and we are in need to speedup the startup-time, as well, as lowering
> the overall footprint.
> the decision-makeing process is still ongoing, so my task is to force
> the usage of the great xfree86 system .. so i must give good
> arguments
> of its usability ;-), e.g.:
>   - hardware acceleration 2D/3D (DRI, OpenGL)
>   - scarlet
>   - siliconmotion
> 
>   - open platform
>   - huge amount of high level api's
>   - etc.
> 
> any ideas and hints are .. of course welcome
> 
> +++
> 
> i love xfree86 architecture ;-)
> 
> cheers, sven
> - -- 
> health & wealth
> mailto:[EMAIL PROTECTED]
> www   : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/
> voice : +49-5121-999600 ; fax : +49-5121-999602
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iD8DBQE+YoWtHdOA30NoFAARAiIAAJ9IRXLPLIqPF3Zw5FRhj2b2fL7cWACglWzj
> 3MJ5w8YBubnPBmJYd1jfqWQ=
> =hrKy
> -END PGP SIGNATURE-
> 
> ___
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel


__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: Multiple Video Consoles

[Alex Deucher]

Jonathan,

   could you also post your XF86Config file?  I have some ideas on how
to extend this.  It's still kind of a hack, but here goes:

add an option to the radeon driver, say "MergedFB" or something like
that.  when that option is set to TRUE, it would skip the sections of
code that you have commented out.

next add "sub" options for "MergedFB"  like:

Option "MFB-Xres" "2048"
Option "MFB-Yres" "768"

these would set the virtualX and Y instead of having to hardcode them.

it's still hackey, but would clean it up a bit and allow run time
configuration.

Alex

--- Jonathan Thambidurai <[EMAIL PROTECTED]> wrote:
>   I posted the following message to the DRI-devel lists the day before
> yesterday and was told it might be of interest to this discussion. 
> Additionally, I have attached some diffs, contrary to what is said as
> follows.
> 
> 
> I am pleased to report that thanks to the guidance Jens Owens gave in
> a
> previous message, I have made 3D work on two heads simultaneously
> (IIRC,
> the ATI Windows XP drivers didn't do this).  I have not provided a
> diff
> because it is quite a hack and very system specific, at the moment. 
> Effectively, I forced the virtual size to be 2048x768, hacked the
> RADEONDoAdjustFrame() function to fix views as I wanted them, used
> the
> default cloning stuff to setup the second monitor, and removed all
> the
> conditionals that were preventing dual-head+DRI from working.  I had
> to
> enable Xinerama (even though I have only one screen in the server
> setup)
> in the config file; otherwise, the desktop would end at 1024 instead
> of
> 2048.  The problem I mentioned in a previous post -- not enough
> memory
> for direct rendering w/ two screens -- was solved when I set it to 16
> bpp.  Does anyone have any ideas for a more elegant implementation of
> this functionality, especially where the config file is concerned? 
> This
> is the first real code I have done in the Xserver and any input would
> be
> appreciated.
> 
> --Jonathan Thambidurai
> 
> 
> p.s. If there is something strange about the diffs, please tell me;
> it
> is the first time I generated any
> > --- /usr/local/src/XFree86.current/xc/programs/Xserver/GL/dri/dri.c
> 2002-12-05 10:26:57.0 -0500
> +++ dri.c 2003-03-03 18:29:30.0 -0500
> @@ -137,13 +137,13 @@
>  #endif
>  
>  #if defined(PANORAMIX) || defined(XFree86LOADER)
> -if (xineramaInCore) {
> - if (!noPanoramiXExtension) {
> - DRIDrvMsg(pScreen->myNum, X_WARNING,
> - "Direct rendering is not supported when Xinerama is enabled\n");
> - return FALSE;
> - }
> -}
> +/* if (xineramaInCore) { */
> +/*   if (!noPanoramiXExtension) { */
> +/*   DRIDrvMsg(pScreen->myNum, X_WARNING, */
> +/*   "Direct rendering is not supported when Xinerama is
> enabled\n"); */
> +/*   return FALSE; */
> +/*   } */
> +/* } */
>  #endif
>  
>  drmWasAvailable = drmAvailable();
> > ---
>
/usr/local/src/XFree86.current/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c
> 2003-02-04 20:48:27.0 -0500
> +++ radeon_driver.c   2003-03-03 19:16:23.0 -0500
> @@ -2754,24 +2754,29 @@
>  xf86SetCrtcForModes(pScrn, 0);
>  
>  /* We need to adjust virtual size if the clone modes have larger
> - * display size.
> + * display size. JDTHAX04: hardcoding large virtual area
>   */
>  if (info->Clone && info->CloneModes) {
>   DisplayModePtr  clone_mode = info->CloneModes;
>   while (1) {
> - if ((clone_mode->HDisplay > pScrn->virtualX) ||
> - (clone_mode->VDisplay > pScrn->virtualY)) {
> - pScrn->virtualX =
> - pScrn->display->virtualX = clone_mode->HDisplay; 
> - pScrn->virtualY =
> - pScrn->display->virtualY = clone_mode->VDisplay; 
> - RADEONSetPitch(pScrn);
> - }
> +/*   if ((clone_mode->HDisplay > pScrn->virtualX) || */
> +/*   (clone_mode->VDisplay > pScrn->virtualY)) { */
> +/*   pScrn->virtualX = */
> +/*   pScrn->display->virtualX = clone_mode->HDisplay;  */
> +/*   pScrn->virtualY = */
> +/*   pScrn->display->virtualY = clone_mode->VDisplay;  */
> +/*   RADEONSetPitch(pScrn); */
> +/*   } */
>   if (!clone_mode->next) break;
>   clone_mode = clone_mode->next;
>   }
>  }
>  
> +pScrn->virtualX = pScrn->display->virtualX = 2048;
> +pScrn->virtualY = pScrn->display->virtualY = 768;
> +RADEONSetPitch(pScrn);
> +xf86DrvMsg(pScrn->scrnIndex, X_NOTICE,
> +"JDT HACK WORKING\n");
>  pScrn->currentMode = pScrn->modes;
>  xf86PrintModes(pScrn);
>  
> @@ -3463,18 +3468,18 @@
>   info->directRenderingEnabled = FALSE;
>   else {
>   /* Xinerama has sync problem with DRI, disable it for now */
> - if (xf86IsEntityShared(pScrn->entityList[0])) {
> - info->directRenderingEna

Re: nasty little bug in radeon driver

[Alex Deucher]

send it to [EMAIL PROTECTED] and/or [EMAIL PROTECTED]

Alex

--- [EMAIL PROTECTED] wrote:
> ...
> > > Now it works for me.
> >
> > Thanks,
> >
> > I've committed your fix to the CVS.
> 
> 
> Quick question -- I posed a patch to
> xc/programs/Xserver/hw/xfree86/os-support/bsd/alpha_video.c on Monday
> which makes X build properly on FreeBSD alpha - I asked if there were
> a
> better way to submit patches and I'm still wondering if I need to do
> something to get this patch accepted and put in... I've checked via
> cvsweb
> and the cvs repository doesn't have my patch...
> 
> Is there someone in particular that I should contact about the patch?
> 
> Fred Clift
> 
> ___
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel


__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: [XFree86] ati radeon 9000 tv-out on xfree 4.3

[Alex Deucher]

also check out GATOS -- http://gatos.sf.net

Alex

--- Olivier Chapuis <[EMAIL PROTECTED]> wrote:
> On Sun, Mar 09, 2003 at 04:21:52PM +0100, Aleksandar Simonovski
> wrote:
> > is tv-out supported with ati radeon 9000 on xfree 4.3
> > 
> 
> I do not think so. However, there is a tool named "atitvout"
> (do a freshmeat search). With some chance you will have tvout:
> 
> - boot with your tvout connector connected to your tv.
> - try all the atitvout command; maybe some will work
> 
> This tool is for ATI Rage Mobility P/M. I can get only black/white
> tv out with my ATI Radeon Mobility M7 LW.
> 
> On the other hand, we can read this in the ati.com Linux/XFree86
> faq:
> 
> "ATI is investigating the possibility of supporting TV Out under
> Linux for products which include this feature."
> 
> So, it will be maybe possible to have a better tv out support
> for ati cards in a near future. My problem here is that I do not
> know how to ask ATI for support (here tv out technical doc).
> 
> Maybe an XFree developer which has contact with ATI can help
> here?
> 
> Regards, Olivier
>  
> ___
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel


__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: Using Linux socket operations in a driver

[Alex Deucher]

the v4l driver interfaces with the kernel v4l drivers.  I believe that
driver uses some linux includes.  There my be an "X" way of doing
socket ops though...

Alex

--- Paul Evans <[EMAIL PROTECTED]> wrote:
> I'm (still) writing an output driver for a network attached device.
> My
> question of the day is:
> 
> How can I call the usual socket operations from an XFree output
> driver?
> There are dire warnings about not including the usual system include
> files
> (sys/types.h and sys/socket.h).
> 
> -- 
> Paul Evans
> 
> (3rd Year CompSci at Pembroke College, Cambridge, England)
> 
> [EMAIL PROTECTED] (university)
> [EMAIL PROTECTED] (alternate)
> ICQ# 4135350
> Registered Linux User: 179460
> http://www.srcf.ucam.org/~pe208/
> ___
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel


__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: Thank you for XFree 4.3.0!

[Alex Deucher]

I'm not too familiar with the neomagic cards, but the hardware "mpeg"
acceleration may have just referred to the HW color space conversion of
the Xvideo interface.  If the chip had motion compensation or iDCT
capabilities, I doubt those will ever be supported since no one has
docs to the chip and neomagic no longer makes chips.  The current
Xvideo work was done by looking at reg dumps from the windows drivers. 
Xvmc the X framework for these feature is only accelerated by the i810
driver at the moment.

Alex

--- Marc Giger <[EMAIL PROTECTED]> wrote:
> Hi All!
> 
> I want to thank you ALL for the great work. I have a neomagic
> graphiccard and now it is possible to watch movies in fullscreen
> without interrupts. Also zooming is now possible with the Xvideo
> interface.
> 
> As last a short question:
> 
> I've heard that my neomagic (nm2230) chip should have a hardware mpeg
> decoder?!? Is it true?  If yes can / will it be used by xfree?
> 
> Thank you again!
> 
> Marc Giger
> ___
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel


__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: savage XVideo annoyance

[Alex Deucher]

does Xvideo work if you remove the panning check?  if so i don't see
why we couldn't remove it.  I'll try and check on my savage IX tonight
or tomorrow.

Alex

--- Billy Biggs <[EMAIL PROTECTED]> wrote:
>   On startup, the savage driver protects its call to initialize its
> XVideo code like this (savage_driver.c in 4.2.1 and 4.3):
> 
> if( !psav->NoAccel && !SavagePanningCheck(pScrn) )
> SavageInitVideo( pScreen );
> 
>   The 'SavagePanningCheck()' call checks to make sure that the
> virtual
> desktop resolution is equal to the current HDisplay/VDisplay, that
> is,
> the resolution on startup.
> 
>   A user of my app complained that XVideo wasn't working.  As it
> turned
> out, he had the resolutions listed backwards in his config file, so
> on
> startup virtual != res, no Init called, and hence no XVideo surfaces.
> 
>   I have to wonder if that check is a bug.  It took a long time to
> figure out why there were no XVideo surfaces, especially since no
> message is sent to the log.  I can think of three resolutions:
> 
>   a) Patch to warn to the log file if the PanningCheck call fails.
>   b) Take out the PanningCheck call or rewrite Init to work without
> it.
>   c) Ignore this because some xrandr-relted stuff makes this obsolete
> in
>  4.3 ?
> 
>   I am only qualified to do (a), and have no hardware to test with.
> :-)
> 
>   Thoughts?
> 
> -- 
> Billy Biggs
> [EMAIL PROTECTED]
> ___
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel


__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: A question about wide aspect panels

[Alex Deucher]

It shouldn't be a problem although you may have to generate your own
modeline, since it's a non-standard one.

try one of these sites to generate a modeline:

http://xtiming.sourceforge.net/cgi-bin/xtiming.pl

http://koala.ilog.fr/cgi-bin/nph-colas-modelines

Alex

--- Mark Cuss <[EMAIL PROTECTED]> wrote:
> Hello all,
> 
> I have a question regarding wide aspect LCD panels and XFree...  I'm
> thinking about a new laptop (a Dell Inpsiron 8500) that was a wide
> aspect LCD (1920 x 1200).  I've never run XFree86 on anything other
> than a 4:3 ratio monitor, and am wondering if this wide aspect screen
> would pose a problem?
> 
> Thanks in advance...
> 
> Mark
> 
> Mark Cuss
> Real Time Systems Analyst
> CDL Systems Ltd
> Suite 230
> 3553 - 31 Street NW
> Calgary, Alberta, Canada  T2L 2K7
> Phone (403) 289-1733 ext 226
> Fax (403) 282-1238
> [EMAIL PROTECTED]


__
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: Help writing a accelerator X driver

[Alex Deucher]

You could do it that way.  You might want to look at the dri project
(http://dri.sf.net) though.  That way you can get an idea of how X
talks to the kernel driver and such as well as make your driver
consistant with the rest of the open source drivers out there.  You can
also use the DRI code from another driver, perhaps the r200, as a basis
for your driver.  Also as I recall the r128 driver supported DMA based
Xvideo (overlay), so if you are looking to do that in your driver the
r128 driver would be a good starting point.

Alex

--- dave <[EMAIL PROTECTED]> wrote:
> Help I am writing a X-4.2.x fully accelerator driver
> For NVIDIA video cards .
> 
> It consisted of 2 parts 
>  1. kernel LNVRM (LINUX NVIDIA RESOURCE MANAGER)
>  2. XNVXF (NVIDIA X FREE)
> 
> The kernel part controls the hardware 
> and the X part talks to the kernel part using  (ioctl)
> and the USER part of the hardware using DMA and MMIO  
> 
> All data 2D ,3D ,IMAGE ,VIDEO ,  MPEG , OVERLAY to and from 
> screen MUST Go thou the accelerator and their can 
> be NO! direct access to screen memory can X function
> in this way?? (Complete accelerator driver)
> 
> 


__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: notes on SonicBlue (S3) and S3TC

[Alex Deucher]

what's the status of S3/sonicblue/VIA?  who owns what?  I'd really like
to get savage mx/ix specs, but I fear that possiblity is slipping away
:(

Alex

--- Alexander Stohr <[EMAIL PROTECTED]> wrote:
> Hmm, SonicBlue (aka known as S3) has claimed
> bankrupcy (Chapter 11) recently, so its a changing 
> situation with S3TC compression right now - 
> who will ever buy that patent and charge the world 
> for the next 70 years?
> 
> Of course the prefered solution would be that some
> interested circles buy it as a group and then open
> that technology for offering to the world for free.
> 
> -Alex.
> 
>

__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: notes on SonicBlue (S3) and S3TC

[Alex Deucher]

Well, that's good.  Now if only they would reply to my
queries...perhaps non-electronic mail is better...

Thanks,

Alex

--- Kevin Brosius <[EMAIL PROTECTED]> wrote:
> I don't have any terribly recent info, but s3graphics was still under
> the Via umbrella last time I checked.  They had docs available as
> long
> as you were willing to sign an NDA.  The NDA allows source code
> release,
> so is compatible with XFree86 development.
> 
> -- 
> Kevin
> 
> 
> Alex Deucher wrote:
> > 
> > 
> > what's the status of S3/sonicblue/VIA?  who owns what?  I'd really
> like
> > to get savage mx/ix specs, but I fear that possiblity is slipping
> away
> > :(
> > 
> > Alex
> > 
> > --- Alexander Stohr <[EMAIL PROTECTED]> wrote:
> > > Hmm, SonicBlue (aka known as S3) has claimed
> > > bankrupcy (Chapter 11) recently, so its a changing
> > > situation with S3TC compression right now -
> > > who will ever buy that patent and charge the world
> > > for the next 70 years?
> > >
> > > Of course the prefered solution would be that some
> > > interested circles buy it as a group and then open
> > > that technology for offering to the world for free.
> > >
> > > -Alex.
> > >
> > >
> ___
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel


__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: notes on SonicBlue (S3) and S3TC

[Alex Deucher]

Do you think I could still get savage mx/ix docs?  perhaps if the old
stuff is orphaned, they will lift the NDAs on the docs? not likey I
suspect.  I really want to finish duoview support.  At this point I
think I might be better off just onloading my savage laptop and getting
a laptop with an ati or some more easily contacted chip vendor...

Alex

--- Tim Roberts <[EMAIL PROTECTED]> wrote:
> On Wed, 26 Mar 2003 19:38:35 -0500, Kevin Brosius wrote:
> >
> >I don't have any terribly recent info, but s3graphics was still
> under
> >the Via umbrella last time I checked.  They had docs available as
> long
> >as you were willing to sign an NDA.  The NDA allows source code
> release,
> >so is compatible with XFree86 development.
> 
> S3 Graphics is still a subsidiary of VIA.
> 
> Note, however, that VIA seems to have moved beyond the Savages. 
> Their latest 
> motherboards come with a brand-new graphics architecture they call
> "Castle 
> Rock".  Thus, I strongly suspect the Savages are now orphans.
> 
> >> --- Alexander Stohr <[EMAIL PROTECTED]> wrote:
> >> > Hmm, SonicBlue (aka known as S3) has claimed
> >> > bankrupcy (Chapter 11) recently, so its a changing
> >> > situation with S3TC compression right now -
> 
> It is likely that the compression technology went with the graphics
> group to 
> VIA, and not to SonicBlue.
> 
> >> > who will ever buy that patent and charge the world
> >> > for the next 70 years?
> 
> A U.S. Patent is only good for 17 or 21 years, not 70 years.
> 
> --
> - Tim Roberts, [EMAIL PROTECTED]
>   Providenza & Boekelheide, Inc.
> 
> 
> ___
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel


__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

RE: An ATI Mobility M4 driver for laptops soon ?

[Alex Deucher]

 the standard r128 driver should work for this chipset.  the M4 is r128
based.

Alex

--- [EMAIL PROTECTED] wrote:
> I have a Dell Inspiron 8000(laptop) 1Ghz
> 128MB
> ATI M4 graphics card
> 
> 
> 
> I am having a strange problem.
> 
> I believe that this problem is with XFree86 and it's consistency
> between it's 
> releases for FreeBSD, NetBSD, OpenBSD, Linux.
> 
> I want to know why some drivers for video cards are not included in
> all the 
> distributations for all Unix-like operating systems named above ?
> 
> The XFree86 distributations for each Unix-like operating system
> contains 
> different
> drivers for different drivers.
> 
> For instance, I can configure XFree86 for Linux using the 4.2 series
> it detects that I have an ATI Mobility M4 and proceeds to configure
> it.
> 
> Now when I try this with XFree86 4.2 on FreeBSD, it claims that it
> can't find 
> the driver and fails to configure at all.
> 
> Who do I contact to have the ATI Mobility M4 driver included with all
> XFree86 
> distros
> for NetBSD, FreeBSD, OpenBSD and Linux ?
> 
> -Thanks
> 
> Kevin Marshfield
> 


__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: status of SiS 3d?

[Alex Deucher]

Sis wrote support for the 300 series and it works.  However, when mesa
4.x came out no one ever updated the sis dri stuff to match the new
structure.  so DRI works with the 300 if you use the mesa 3.x libs.  It
shouldn't be too hard to port the sis stuff to mesa 4.x, but there
doesn't seem to be much interest in doing so.  3D support for newer sis
boards probably won't happen cause Sis has changed their policy in
regard to giving out docs to their chips.  3D support for the older sis
boards 6326 or whatever it's called should be possible since docs are
available for that board (there was even a utah-glx driver for it), but
it needs to be written.

Hope that helps,

Alex

--- Julian Graham <[EMAIL PROTECTED]> wrote:
> I'm a little confused about the status of the SiS drivers as
> described by 
> the release notes for >= 4.2.99.  It says:
> 
> > Major SiS driver updates for some of the latest chipsets.
> Unfortunately 
> > the SiS 3D driver has had to be disabled because no one has yet
> taken up 
> > the challenge to port it to Mesa 4.x.
> 
> I'm familiar with Thomas Winischhofer's work on getting SiS hardware 
> functioning to a moderate extent of its capability, but his page
> gives 
> the impression that SiS's policy on Linux development means that real
> 3d 
> support is probably not going to be possible in the forseeable
> future.  
> These release notes seem to indicate otherwise, e.g. that it's merely
> a 
> question of porting -- if this is the case, what exactly needs to be
> done?  
> What information on the hardware is available / still necessary?  Is
> it a 
> question of adding an SiS section to DRI?
> 
> 
> Regards,
> Julian
> 
> ___
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel


__
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: IBM port replicator noise?

[Alex Deucher]

actually I believe the t30 has a full fledged mobility radeon 7500 on
board.  regardless, the issue seems to be that the max res supported by
the DVI port is 1280x1024.  running the port at 1200x1600 is beyond the
specs (and not supported).  I don't really see this as a problem.  if
you run at 1200x1600 you take your chances; if it works great, if not
then you are out of luck.  Frankly most graphics cards I've seen max
out at 1280x1024 on the DVI port.

Alex

--- Michael B Allen <[EMAIL PROTECTED]> wrote:
> Does anyone have any insight into this problem? I can compile from
> source if any has patches they want me to try out. The chip is the
> Radeon
> Mobility 7000 IGP:
> 
>  
>
http://www.ati.com/technology/hardware/mobilityradeon7000IGP/index.html
> 
> Thanks,
> Mike
> 
> --original message to XFree86 list--
> On Sat, 24 May 2003, Michael B Allen wrote:
> 
> I'm trying to get the external dvi-d output on my IBM T30 via port
> replicator to work with my 1600x1200 flat panel. I tried X 4.2 but
> there
> was a lot of garbage on the screen. So I upgraded to X 4.3 and it's
> better but still there are red and green dots in gradient areas. I
> tried
> to take a screenshot but it was clean. IBM's website has this to say:
> 
>   TP A30, A31, T30 - Maximum Digital Video (DVI) Resolution is 1280 x
>   1024 at 60 Hz
> 
>   Symptom
>   When attaching a Digital Flat Panel Display to the Digital Video
>   Interactive (DVI) Connector on the back of the Dock or Port
> Replicator,
>   running 1600 x 1200 resolution, video noise appears on the display.
> 
>   Affected configurations
>   ThinkPad A30, A30p, A31, A31p and T30 computer systems external DVI
>   Connector.
> 
>   Solution
>   Use 1280 x 1024 or lower resolution with the DVI Display.
> 
>   Additional information
>   DVI resolution higher than 1280x1024 is not supported on A30, A31,
>   and T30 ThinkPads.
> 
> But this doesn't say explicitly that it's a hardware problem. The
> noise
> isn't that bad. It's very very close but not quite. Any ideas?
> 
> Thanks,
> Mike
> 


__
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: IBM port replicator noise?

[Alex Deucher]

I suspect it was not designed to handle the bandwidth needed for
1600x1200.  DVI may be the future, but the ports are limited by the
transmitters driving them, just as CRT ports are limited by the RAMDAC.
 As 1600x1200 LCDs become more popular, I'm sure you'll see the
capabilities of DVI ports increase.

Alex


--- Michael B Allen <[EMAIL PROTECTED]> wrote:
> > actually I believe the t30 has a full fledged mobility radeon 7500
> on
> > board.  regardless, the issue seems to be that the max res
> supported by
> > the DVI port is 1280x1024.  running the port at 1200x1600 is beyond
> the
> > specs (and not supported).  I don't really see this as a problem. 
> if
> > you run at 1200x1600 you take your chances; if it works great, if
> not
> > then you are out of luck.  Frankly most graphics cards I've seen
> max
> > out at 1280x1024 on the DVI port.
> 
> So it's a hardware limitation? That's depressing and a little
> shocking. I
> thought DVI was the future.
> 
> So I'm completely SOL. Returning the port replicator and getting the
> docking station is a *lot* more money. It's so close to being usable.
> Perhaps if I put ice cubes all over my laptop, .
> 
> Thanks,
> Mike
> ___
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel


__
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: Input driver devel

[Alex Deucher]

There are some hacks to accomplish this, but I don't think there's
really an elegant way to do this in the current architecture.  Xfree86
5 should address this.

Alex

--- Robert Woerle <[EMAIL PROTECTED]> wrote:
> Hi
> 
> I did make a touchscreen driver for a Tablet PC .
> I also have a calibration utility that writes the new coordinates to
> the 
> XF86Config
> Next step is to make the calibration valid on-the-fly and dont need
> to 
> restart the X-Server ??
> 
> I now want to know how i can issue a SIGNAL to a input driver to
> force 
> him to reread the XF86Config
> 
> I know that this is possible with X somehow .. but i dont see the
> method ???
> 
> Can someone give me adivce on how to do that ?
> 
> Cheers Rob
> -- 
> _
> *Robert Woerle
> Linux & Customer Support*
> *PaceBlade Technology Europe SA*
> phone:+49 89 552 99935
> fax:  +49 89 552 99910
> mobile:   +49 179 474 45 27
> email:[EMAIL PROTECTED] 
> web:  http://www.paceblade.com
> _
> 
> 
> 
> 
> ___
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel


__
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: Writing a new input driver

[Alex Deucher]

I believe the wacom driver is a good starting point.

Alex

--- Marco Lazzarotto <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> I have to write a driver for the ronics touchscreen.
> Since the sample driver is outdated (in the 4.3.0 source
> tree,almost), 
> where do I find a good starting point to do it?
> Thanks in advance
> Marco Lazzarotto
> 


__
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

how to iterate through mode lists

[Alex Deucher]

I'm working on integrating my radeon mergedfb code with xfree86 cvs. 
so far it's working, but now I'm trying to integrate the current clone
code with the mergedfb clone mode.  so far so good.  I'm trying to use
the modes defined for the 1st head as clone modes for the second head
in the even that no metamodes are defined in the XF86Config file
(default behavior).  I just can't seem to get it to work!  How do you
iterate through a mode list?  It seems to be circular.  I'm probably
missing something basic, but my code seems to get stuck in an endless
loop.  Here's what I'm trying to do.  The function
RADEONGenerateModeList() normally takes the list of userdefined
"metamodes" (mode combinations for both heads, ie, 1024x768-800x600
would be the metamode for 1024x768 on the first head and 800x600 on the
second) and parses them, then looks up the equivalent modes names in
the validated modes for each head and then links them into a metamode. 
I have a check at the top to see if metamodes is NULL, if it is then it
iterates over the validated modes for head 1 (i) and looks up the
corresponding mode for head 2 (j) based on the name, then sets the
metamode.  What is the best way to iterate through a mode list?  Am I
even on the right track here?  shouldn't tempmode->next be NULL at the
end of the list?  If not then how do you know how many iterations you
need?

/* default case if no metamodes specified */
if (str == NULL) {
sr = radeonClone;
for (tempmode = i; tempmode != NULL; tempmode = tempmode->next) {
/* look up the mode for each head based on the name */
mode1 = RADEONGetModeFromName(tempmode->name, i);
mode2 = RADEONGetModeFromName(mode1->name, j);
if(!mode2) {
xf86DrvMsg(pScrn->scrnIndex, X_WARNING,
"Mode: \"%s\" is not a supported mode for CRT2\n", mode1->name);
xf86DrvMsg(pScrn->scrnIndex, X_WARNING,
"Skipping metamode \"%s\".\n");
mode1 = NULL;
} else {
/* link the modes into a "metamode" */
result = RADEONCopyModeNLink(pScrn, result, mode1, mode2, sr);
mode1 = NULL;
mode2 = NULL;
}  
}
return result;
}


Thanks for any advice,

Alex

__
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

xfixes extension

[Alex Deucher]

Now that 4.3.0 is out, what is the status of xfixes?  I'd like to see
it included again for 4.4.0 or 5 or whatever the next release will be. 
it fixed some annying behavior in X.  if not xfixes, what about another
extension offering similar functionality?

Thoughts?

Alex


__
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: how to iterate through mode lists

[Alex Deucher]

If that's the case then's what's the best way to iterate through the
mode list without getting stuck in an endless loop?  It's probably
somehting simple, but it's just not coming to me...

Alex

--- Dr Andrew C Aitchison <[EMAIL PROTECTED]> wrote:
> 
> I have only looked at this code briefly and long ago, but I think 
> that having this circular may have been deliberate.
> It would certainly simplify handling /.
> Dealing with edge cases would be more effort, especially if 
> XFree86-VidModeExtension allows clients to to add and remove modes
> while the server remains running (I think it does).
> 
> -- 
> Dr. Andrew C. Aitchison   Computer Officer, DPMMS, Cambridge
> [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna
> 


__
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: how to iterate through mode lists

[Alex Deucher]

yeah, that's the way to do it... I feel like an idiot... it's been too
long since my old CS classes...

Thanks to all who replied,

Alex

--- Sven Luther <[EMAIL PROTECTED]> wrote:
> On Fri, May 30, 2003 at 08:24:31AM -0700, Alex Deucher wrote:
> > If that's the case then's what's the best way to iterate through
> the
> > mode list without getting stuck in an endless loop?  It's probably
> > somehting simple, but it's just not coming to me...
> 
> For a circular list, you need to keep the original pointer around,
> and
> then travel the list until you get NULL (for the non circular list)
> or
> the original pointer, Something like :
> 
> for (test=FALSE, p=modes; p!=NULL && (test && p != modes); test=TRUE,
> p = p->next);
> 
> Fully untested, and may contain typos, but you get the idea.
> 
> Friendly,
> 
> Sven Luther


__
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

re: [PATCH] radeon mergedfb support for cvs

[Alex Deucher]

BTW, bugzilla reference for this feature is here:
http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=276
Please test and post any comments or issues.

Thanks,

Alex

---

The attached patch adds mergedfb support (a single framebuffer with two
viewports looking into it) to the radeon driver.  the options are
consistant with the sis and mga drivers.  I've also replaced the old
clone mode with the clone mode supplied by the mergedfb code.  It's
behavior follows that of the previous previous clone code.  I've tested
it on an a radeon m6.  HW accelerated 3D works on both heads.  Please
consider for inclusion in xfree86 cvs.

Thanks,

Alex

__
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: RFC: OpenGL + XvMC

[Alex Deucher]

Just curious, as I'm not too familiar with XvMC yet, but would this
provide another Xv adapter that used the 3D texture engine to display
videos rather than othe video overlay?  or something else.  Sorry for
my ignorance.

Thanks,

Alex

--- Mark Vojkovich <[EMAIL PROTECTED]> wrote:
>I'd like to propose adding a XvMCCopySurfaceToGLXPbuffer function
> to XvMC.  I have implemented this in NVIDIA's binary drivers and
> am able to do full framerate HDTV video textures on the higher end
> GeForce4 MX cards by using glCopyTexSubImage2D to copy the Pbuffer
> contents into a texture.
> 
> 
> Status
> XvMCCopySurfaceToGLXPbuffer (
>   Display *display,
>   XvMCSurface *surface,
>   XID pbuffer_id,
>   short src_x,
>   short src_y,
>   unsigned short width,
>   unsigned short height,
>   short dst_x,
>   short dst_y,
>   int flags
> );
> 
>This function copies the rectangle specified by src_x, src_y,
> width,
>   and height from the XvMCSurface denoted by "surface" to offset
> dst_x, dst_y 
>   within the pbuffer identified by its GLXPbuffer XID "pbuffer_id".
>   Note that while the src_x, src_y are in XvMC's standard left-handed
>   coordinate system and specify the upper left hand corner of the
>   rectangle, dst_x and dst_y are in OpenGL's  right-handed coordinate
> 
>   system and denote the lower left hand corner of the destination 
>   rectangle in the pbuffer.
> 
> "Flags" may be XVMC_TOP_FIELD, XVMC_BOTTOM_FIELD or
> XVMC_FRAME_PICTURE.
>   If flags is not XVMC_FRAME_PICTURE, the src_y and height are in
> field
>   coordinates, not frame.  That is, the total copyable height is half
>   the height of the XvMCSurface.  
> 
> XvMCCopySurfaceToGLXPbuffer does not return until the copy to the
>   pbuffer has completed.  XvMCCopySurfaceToGLXPbuffer is pipelined
>   with XvMCRenderSurface so no explicit synchronization between 
>   XvMCRenderSurface and XvMCCopySurfaceToGLXPbuffer is needed.
>   
> The pbuffer must be of type GLX_RGBA, and the destination of the
>   copy is the left front buffer of the pbuffer.  Success is returned
>   if no error occured, the error code is returned otherwise.
> 
> Possible Errors:
> 
>XvMCBadSurface - The surface is invalid.
> 
>BadDrawable - The pbuffer_id is not a valid pbuffer.
> 
>BadMatch - The pbuffer is not of type GLX_RGBA or the
>   pbuffer does not have a front left buffer.
> 
>   XvMCCopySurfaceToGLXPbuffer is supported if the following flag:
> 
> #define XVMC_COPY_TO_PBUFFER 0x0010
> 
>   is set in the XvMCSurfaceInfo's flags field.
> 
>   I'd like to bump the API version up to 1.1 and add this.  
> Comments?
> 
> 
>   Mark.
> 


__
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: how to iterate through mode lists

[Alex Deucher]

thanks,  I got it working.  The working patch against CVS in up on
bugzilla:
http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=276

Alex

--- Egbert Eich <[EMAIL PROTECTED]> wrote:
> Alex Deucher writes:
>  > I'm working on integrating my radeon mergedfb code with xfree86
> cvs. 
>  > so far it's working, but now I'm trying to integrate the current
> clone
>  > code with the mergedfb clone mode.  so far so good.  I'm trying to
> use
>  > the modes defined for the 1st head as clone modes for the second
> head
>  > in the even that no metamodes are defined in the XF86Config file
>  > (default behavior).  I just can't seem to get it to work!  How do
> you
>  > iterate through a mode list?  It seems to be circular.  I'm
> probably
>  > missing something basic, but my code seems to get stuck in an
> endless
>  > loop.  Here's what I'm trying to do.  The function
>  > RADEONGenerateModeList() normally takes the list of userdefined
>  > "metamodes" (mode combinations for both heads, ie,
> 1024x768-800x600
>  > would be the metamode for 1024x768 on the first head and 800x600
> on the
>  > second) and parses them, then looks up the equivalent modes names
> in
>  > the validated modes for each head and then links them into a
> metamode. 
>  > I have a check at the top to see if metamodes is NULL, if it is
> then it
>  > iterates over the validated modes for head 1 (i) and looks up the
>  > corresponding mode for head 2 (j) based on the name, then sets the
>  > metamode.  What is the best way to iterate through a mode list? 
> Am I
>  > even on the right track here?  shouldn't tempmode->next be NULL at
> the
>  > end of the list?  If not then how do you know how many iterations
> you
>  > need?
> 
> The mode list is a ring. Therefore tempmode->next will never be NULL.
> 
> Why don't you try this?
> 
>  > 
>  > /* default case if no metamodes specified */
>  > if (str == NULL) {
>  >sr = radeonClone;
>if ((tempmode = i) != NULL) 
>   while (1) {
>  > /* look up the mode for each head based on the name */
>  >mode1 = RADEONGetModeFromName(tempmode->name, i);
>  >mode2 = RADEONGetModeFromName(mode1->name, j);
>  >if(!mode2) {
>  >xf86DrvMsg(pScrn->scrnIndex, X_WARNING,
>  >"Mode: \"%s\" is not a supported mode for CRT2\n",
> mode1->name);
>  >xf86DrvMsg(pScrn->scrnIndex, X_WARNING,
>  >"Skipping metamode \"%s\".\n");
>  >mode1 = NULL;
>  >} else {
>  > /* link the modes into a "metamode" */
>  >result = RADEONCopyModeNLink(pScrn, result, mode1, mode2, sr);
>  >mode1 = NULL;
>  >mode2 = NULL;
>  >}  
>   tempmode = tempmode->next;
>   if (tempmode == i || tempmode == NULL)
>   break;
>  >}
>  > return result;
>  > }
>  > 
>  > 
> 
> Egbert.
> ___
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel


__
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: status of SiS 3d?

[Alex Deucher]

right now just the 300 series (300, 305?, 540, 630/S/ST, 730) have DRI
support.  the old series 6326, 620, 530 don't have DRI support, but but
there are docs available (on the dri website I think) to write a DRI
driver; there was also a utah-glx driver for the that series.  I think
the 6327 might have been the internal sis name for the 300 series,
although that's just a guess on my part.  The 6326 and the 300 series
might be simialr enough to support them both with one driver, but I
don't know.  Thomas Winischhofer would probably be a better person to
ask.  I was thinking of tackling this myself to try and learn more
about the DRI, and I'd be willing to try to help you if you wanted to. 
I'll even provide cards.  sis 300 series cards are also very cheap. 
What I'd like to know is how different the 3D engine is on the 315
series is from the 300 series, and whether that could be supported at
some point.  It's doubtful however since sis refuses to hand out docs
any more.

BTW, read over thomas' sis site for an overview of the different sis
chips and features:
http://www.winischhofer.net/linuxsisvga.shtml
and
http://www.winischhofer.net/sisdri.shtml

Alex

--- Ian Romanick <[EMAIL PROTECTED]> wrote:
> Alex Deucher wrote:
> > Sis wrote support for the 300 series and it works.  However, when
> mesa
> > 4.x came out no one ever updated the sis dri stuff to match the new
> > structure.  so DRI works with the 300 if you use the mesa 3.x libs.
>  It
> > shouldn't be too hard to port the sis stuff to mesa 4.x, but there
> > doesn't seem to be much interest in doing so.  3D support for newer
> sis
> > boards probably won't happen cause Sis has changed their policy in
> > regard to giving out docs to their chips.  3D support for the older
> sis
> > boards 6326 or whatever it's called should be possible since docs
> are
> > available for that board (there was even a utah-glx driver for it),
> but
> > it needs to be written.
> 
> Which boards did the DRI driver support?  I see 6327 sprinkled all
> over 
> the driver, but not much else.  Would it also support the 6326?  I
> see 
> those on eBay for less than $15 shipped.  If the driver supports that
> 
> chip, I might get one and update the driver to just get "Can I have
> 3D 
> on my old SiS card?" out of the FAQ. :)
> 


__
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: status of SiS 3d?

[Alex Deucher]

--- Ian Romanick <[EMAIL PROTECTED]> wrote:
> 
> I certainly wouldn't buy one to replace my Radeon 8500! :)  It would
> be 
> exclusively to update the drive.  It's the same reason I would be a 
> Gamma card w/an R2 rasterizer...too bad there are *none* on eBay. 
> After 
> I realized that, I pretty much give up any hopes of the gamma driver 
> ever being updated.  That is, unless 3dlabs were to give out 
> documentation for an R3 or R4 rasterizer.
> 

I've heard 3dlabs is pretty good about giving out docs to driver
developers, although that was before creative labs bought them.

Alex


__
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: Fw: Reverse engineering Windows Radeon IGP320/340 driver?

[Alex Deucher]

--- Wouter Bijlsma <[EMAIL PROTECTED]> wrote:
> 
> It's a pity the DRI folks don't have access to the hardware. I do.
> But I'm not a driver developer (though I'm quite skilled in C,
> assembler and graphics code). Would it be a bad thing for me to try
> and find out if the existing 7000 driver can be adapted to work on
> the IGP chipsets? Would it actually be possible to get something
> useful out of this, or is this to complex or involved for me? Would
> the results be of any use to the DRI developers? I'm not talking
> about reverse engineering the whole driver, only finding out if the
> IGP chipset is very different from the 7000.
> 

What you could do is compare the current IGP 2D code in CVS with the
r100 code, then look at differences and start messing with the r100 DRI
driver.  The fix might not be all that complicated.

Alex


__
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: Getting Dual Independent Heads to work on Debian(sid) on iBook

[Alex Deucher]

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.

Alex

--- "Andreakis, Dean (MED)" <[EMAIL PROTECTED]> wrote:
> I am trying to enable dual independent heads on my 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 then just used the same basic changes I made to the
> Dell/RH9 XF86Config file on the iBook/Debian system. When I did this
> the
> iBook basically just cloned the display to the external CRT instead
> of
> providing a second independent coordinate system on the external CRT
> like I wanted. Here is my XF86Config-4 file on the iBook:
> 
> Section "Files"
>   RgbPath  "/usr/X11R6/lib/X11/rgb"
>   FontPath "unix/:7100"
> EndSection
> 
> Section "Module"
>   Load  "dbe"
> Load  "GLcore"
>   Load  "extmod"
> # Load  "fbdevhw"
>   Load  "glx"
>   Load  "record"
>   Load  "freetype"
>   Load  "type1"
>   Load  "dri"
> Load  "xtrap"
> Load  "speedo"
> EndSection
> 
> Section "InputDevice"
>   Identifier  "Keyboard0"
>   Driver  "keyboard"
>   Option  "XkbRules" "xfree86"
>   Option  "XkbModel" "pc105"
>   Option  "XkbLayout" "us"
> EndSection
> 
> Section "InputDevice"
>   Identifier  "Mouse0"
>   Driver  "mouse"
>   Option  "Protocol" "IMPS/2"
>   Option  "Device" "/dev/input/mice"
>   Option  "ZAxisMapping" "4 5"
>   Option  "Emulate3Buttons" "no"
> EndSection
> 
> Section "InputDevice"
>   Identifier  "DevInputMice"
>   Driver  "mouse"
>   Option  "Protocol" "IMPS/2"
>   Option  "Device" "/dev/input/mice"
>   Option  "ZAxisMapping" "4 5"
>   Option  "Emulate3Buttons" "no"
> EndSection
> 
> Section "Monitor"
> Identifier "lcd"
> VendorName "Generic"
> ModelName "Flat Panel 1400x1050"
> Option "dpms"
> EndSection
> 
> Section "Monitor"
>   Identifier   "external-21in"
>   VendorName   "Monitor Vendor"
>   ModelName"Dell 1800FP (Analog)"
>   Option  "dpms"
> EndSection
> 
> Section "Device"
> Identifier "radeon-lcd"
> VendorName "ATI"
> BoardName "ATI Radeon"
> Driver "radeon"
> Screen 0
> #BusID  "PCI:0:16:0"
> #Option "UseFBDev"
> EndSection
> 
> Section "Device"
> Identifier "radeon-external"
> VendorName "ATI"
> BoardName "ATI Radeon"
> Driver "radeon"
> Screen 1
> BusID  "PCI:0:10:0"
> EndSection
> 
> Section "Screen"
> Identifier "lcd-screen"
> Device "radeon-lcd"
> Monitor "lcd"
> DefaultDepth 24
> 
> Subsection "Display"
> Depth 8
> Modes "1024x768" "800x600" "640x480"
> EndSubsection
> 
> Subsection "Display"
> Depth 15
> Modes "1024x768" "800x600" "640x480"
> EndSubsection
> 
> Subsection "Display"
> Depth 16
> Modes "1024x768" "800x600" "640x480"
> EndSubsection
> 
> Subsection "Display"
> Depth 24
> Modes "1024x768" "800x600" "640x480"
> EndSubsection
> EndSection
> 
> Section "Screen"
> Identifier "external-21in-screen"
> Device "radeon-external"
> Monitor "external-21in"
> DefaultDepth 24 
> SubSection "Display"
>   Depth24 
>   Modes"1024x768" "800x600" "640x480"
> EndSubsection
> EndSection
> 
> # Dual-head layout with a large monitor on the right of the LCD.
> # Really this layout will work for any monitor that supports DDC
> # queries.  It may give you a higher resolution than you'd prefer
> though.
> Section "ServerLayout"
> Identifier "default"
> InputDevice "Keyboard0" "CoreKeyboard"
> InputDevice "Mouse0" "CorePointer"
> InputDevice "DevInputMice" "SendCoreEvents"
> Screen "lcd-screen"
> Screen "external-21in-screen" LeftOf "lcd-screen"
> EndSection
> 
> Section "DRI"
>   Group0
>   Mode 0666
> EndSection
> 
> 
> The only odd behaviour I have noticed is around the BusID settings
> (in
> the Device section) between the iBook and the Dell:
> 
> 1. On the Dell system I set the BusID to the same value (as reported
> by
> lspci or X --scanpci) in both Device sections and everything is ok. 
> 
> 2. On the iBook if I set both BusID's in both device sections to
> 0:10:0
> then X won't startup even though this is the ID reported by lspci for
> the ATI chip. If I just set the BusID in the device section
> associated
> with the external CRT to 0:10:0 then X will start and the colors are
> ok
> but there are scrolling lines in the lcd panel. Also, if I run
> glxinfo
> then it reports information on

Re: Symbol unresolved problems..

[Alex Deucher]

I had this problem as well at one point when I was messing with the
savage driver.  What was weird was I hadn't messed with any of the vbe
stuff.  I think it ended up being a bad pointer reference or something
like that.  also, if you are attempting to mess with programming
dualhead, you need to turn off the "usebios" mode stuff or it will muck
up the crtc's.

Alex

--- Jason Kim <[EMAIL PROTECTED]> wrote:
> Thank you ...
> 
> No I didn't modify this symbol..  This symbol is "vbeFree".
> 
> I didn't touch anything about Savage device driver, but
> savage_driver.o module can't resolve the vbeFree symbol anymore...
> T.T
> 
> jason
> 


__
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: Getting Dual Independent Heads to work on Debian(sid) on iBook

[Alex Deucher]

this is from the DRI (front, back, and depth buffers) not the 2D driver
I think.

Alex

--- "Andreakis, Dean (MED)" <[EMAIL PROTECTED]> wrote:
> 
> (WW) RADEON (0): Static buffer allocation failed -- need at least
> 9216
> kB video memory
> (II) RADEON (0): Memory manager initialzed to (0,0) (10124,2048)
> (II) RADEON (0): Reserved area from (0,768) to (1024, 770)
> (II) RADEON (0): Largest offscreen area available: 1024 x 1278
> 
> ...
> 
> (WW) RADEON (1): Static buffer allocation failed -- need at least
> 9216
> kB video memory
> (II) RADEON (1): Memory manager initialzed to (0,0) (10124,2048)
> (II) RADEON (1): Reserved area from (0,768) to (1024, 770)
> (II) RADEON (1): Largest offscreen area available: 1024 x 1278
> 
> It seems confusing to me since I have 16MBytes of video memory
> installed. For 1024x768x32bpp mode (worste case) this only calculates
> to
> 3145728 bytes per screen but yet its telling me I need 9216 kBytes
> per
> screen...h...must be more buffer allocation needed by the chip
> then
> just the on-screen area frame buffer
> 
> any thoughts?
> 
> thx...
> 
> -dean andreakis


__
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: Getting Dual Independent Heads to work on Debian(sid) on iBook

[Alex Deucher]

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 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 trying to load...
> 
> thx,
> 
> -dean andreakis
> 
> On Fri, 2003-06-13 at 14:47, Alex Deucher wrote:
> > this is from the DRI (front, back, and depth buffers) not the 2D
> driver
> > I think.
> > 
> > Alex
> > 
> > --- "Andreakis, Dean (MED)" <[EMAIL PROTECTED]> wrote:
> > > 
> > > (WW) RADEON (0): Static buffer allocation failed -- need at least
> > > 9216
> > > kB video memory
> > > (II) RADEON (0): Memory manager initialzed to (0,0) (10124,2048)
> > > (II) RADEON (0): Reserved area from (0,768) to (1024, 770)
> > > (II) RADEON (0): Largest offscreen area available: 1024 x 1278
> > > 
> > > ...
> > > 
> > > (WW) RADEON (1): Static buffer allocation failed -- need at least
> > > 9216
> > > kB video memory
> > > (II) RADEON (1): Memory manager initialzed to (0,0) (10124,2048)
> > > (II) RADEON (1): Reserved area from (0,768) to (1024, 770)
> > > (II) RADEON (1): Largest offscreen area available: 1024 x 1278
> > > 
> > > It seems confusing to me since I have 16MBytes of video memory
> > > installed. For 1024x768x32bpp mode (worste case) this only
> calculates
> > > to
> > > 3145728 bytes per screen but yet its telling me I need 9216
> kBytes
> > > per
> > > screen...h...must be more buffer allocation needed by the
> chip
> > > then
> > > just the on-screen area frame buffer
> > > 
> > > any thoughts?
> > > 
> > > thx...
> > > 
> > > -dean andreakis
> > 
> > 
> > __
> > Do you Yahoo!?
> > Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
> > http://calendar.yahoo.com
> > ___
> > Devel mailing list
> > [EMAIL PROTECTED]
> > http://XFree86.Org/mailman/listinfo/devel
> ___
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel


__
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

[PATCH] radeon mergedfb support for cvs

[Alex Deucher]

The attached patch adds mergedfb support (a single framebuffer with two
viewports looking into it) to the radeon driver.  the options are
consistant with the sis and mga drivers.  I've also replaced the old
clone mode with the clone mode supplied by the mergedfb code.  It's
behavior follows that of the previous previous clone code.  I've tested
it on an a radeon m6.  HW accelerated 3D works on both heads.  Please
consider for inclusion in xfree86 cvs.

Thanks,

Alex

__
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

mergedfb-cvs.diff
Description: mergedfb-cvs.diff

Re: looking for technical doc

[Alex Deucher]

unfortunately, you have the two chips for which you are least likely to
find documentation.  the neomagic driver was written for XF 3.3 under a
special agreement with neomagic.  the driver was originally binary
only, but eventually the source was released.  Neomagic no longer makes
graphics chips.  I'm not sure they even have the databooks anymore. 
You might be able to get docs for the nvidia chips, but you'll have to
sign an NDA, and I doubt you'll be able to release the source.  your
best bet is to look at the existing xfree drivers.

Good Luck,

Alex

--- Sebastien DI MERCURIO <[EMAIL PROTECTED]> wrote:
> HEllo,
> 
> In fact, my mail is not directly related to Xfree
> project, neither X11. 
> 
> I am building my own OS, for fun and learning purpose,
> and now want to build some graphical interface. I've
> got 2 computers, on using a nVidia Geforce 2 MX, the
> other a neomagic magicmedia 256 AV. But, even after
> lot of mails and phone calls, I was unable to get any
> piece of documentation from neither companies.
> 
> Because on Xfree both chips are supported, I would
> like to know where you have found your doc ? Is it
> possible for you to send me them ?
> 
> Thank you very much.
> Have a nice day
> 
> Sebastien DI MERCURIO
> 


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: good card with full spec available

[Alex Deucher]

You can download the chips databooks right off their web site. although
it might be hard finding a card (must chips chips are in latops).  I've
heard 3dlabs is also good about giving out docs.  Matrox cards prior to
the parhelia are also well supported and you can download the databooks
from matrox's developer website.  I'd say that would be your best bet.

Alex

--- Sebastien DI MERCURIO <[EMAIL PROTECTED]> wrote:
> I am looking for a good video card with full specs available for low 
> level developpement. I don't care for 3D rendering, I'm only
> interrested 
> by 2D graphics.
> 
> Thank you
> Sebastien
> 



__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: Getting additional info from an XInput driver

[Alex Deucher]

I'm not sure Xinput really supports this sort of functionality right
now.  Support for this may be something for 5.0.

Alex

--- Divide by Zero <[EMAIL PROTECTED]> wrote:
> On Tuesday 24 of June 2003 23:16, Brad Hards wrote:
> > On Wed, 25 Jun 2003 00:34 am, Divide by Zero wrote:
> > > I'm trying to extend the standard mouse_drv.o driver to enable it
> to read
> > > battery and RF channel status from a wireless mouse. I have
> googled the
> > > mouse protocol, so I know how to get the information from the
> mouse. The
> > > problem is that I can't find any way to get this information thru
> XInput
> > > from the driver to an application. Does anybody know how to read
> > > additional info of this kind from a (core pointer) driver?
> >
> > Why do this in X?
> > http://www.frogmouth.net/logitech-applet-0.3.tar.gz
> >
> > Even if you do want to do it in X, you can't do it over the mouse
> protocol
> > - the information simply isn't there. You have to do vendor
> specific
> > transfers.
> 
> I'm writing about PS/2 mice, not USB. And the info is there, have a
> look here:
> http://www.dqcs.com/logitech/PS2ppSpec.htm
> and I have no problem retrieving it, for example using this simple
> patch over 
> mouse.c:
> @@ -1416,6 +1416,9 @@
> dw = (pBuf[2] & 0x08) ? (pBuf[2] & 0x0f) - 16 :
> (pBuf[2] & 0x0f);
> break;
> +case 5:   /* wireless status type packet */
> +xf86Msg(X_INFO, "%s: battery level: %d, RF channel: %d\n", 
> pInfo->name,
> +  pBuf[2] & 0x07, (pBuf[2] >> 3) & 0x07);
> case 0: /* device type packet - shouldn't
> happen */
> default:
> buttons |= (pMse->lastButtons & ~0x07);
> 
> (I have Logitech Cordless MouseMan Optical). What the problem is is
> getting 
> the info from the driver to a client (once it has been read from the
> mouse).
> 
> I hope that clears it out.
> -- 
> Divide by Zero (is not really dividing by zero)
> 
> 
> ___
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: Getting additional info from an XInput driver

[Alex Deucher]

perhaps you could write a kernel driver and wrap it with an X driver
(although you'd lose multiplatform capabilities).  I'm not that
familiar with XInput.

Alex

--- Divide by Zero <[EMAIL PROTECTED]> wrote:
> On Wednesday 25 of June 2003 05:39, Alex Deucher wrote:
> > I'm not sure Xinput really supports this sort of functionality
> right
> > now.  Support for this may be something for 5.0.
> 
> I was hoping for some kind of workaround, ie. a virtual device or
> something 
> similar.
> 
> -- 
> Divide by Zero (is not really dividing by zero)
> 


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

SiS news

[Alex Deucher]

I just saw this on extremetech today:

http://www.extremetech.com/article2/0,3973,1101038,00.asp

Looks like SiS is spinning off it's graphics chip division.  perhaps
this could mean better access to databooks!

time will tell I suppose.

Alex

__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: root window

[Alex Deucher]

there is a work around for root window file managers like nautilus or
KDE in xsnow and xpenguins.  you might also want to check the nautilus
source or gnome source for the root window code, or ask on one of the
gnome lists.

Alex

--- Daniel Godas Lopez <[EMAIL PROTECTED]> wrote:
> i have made a program that changes the background image of the root
> window; it orks fine but when u use nautilus the besktop background u
> see is not the root window, so changin the root windows pixmap doesnt
> change the background (it changes but it remains behind the nautilus
> window), does anybody know how to get the nautilus window ID so i can
> change its background pixmap?
> -- 
> 



__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: nautilus root window

[Alex Deucher]

try your query on Nautilus-devel (http://www.gnome.org).  one of the
nautilus developers should be able to answer your question.

Alex

--- Daniel Godas Lopez <[EMAIL PROTECTED]> wrote:
> i have been trying to paint on the root window, i am using an include
> file (vroot.h) that defines a function to get the virtual root window
> the window manager sets but i guess nautilus puts another window on
> top
> of that one because i can only see the canges when i stop nautilus,
> doe
> sanybody know how to get nautilus' root window?
> 
> thx
> -- 
> 


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: Dell C400 fix applied to 855GM?

[Alex Deucher]

why aren't the windows drivers affected?  they must be a way around it
without needing a new bios...  The same thing was claimed the last time
around with the 830s and dell never fixed the bios, but someone came up
with a work around.

Alex

--- Hope Merritt <[EMAIL PROTECTED]> wrote:
> All,
> 
> The patches will not work do to a limitation in the
> Dell system BIOS and Intel VBIOS.  Dell locks their
> pre-allocated (once called stolen) memory at 1MB and
> therefore you will be limited in modes on Linux since
> the VBIOS limits its modes to the amount of
> pre-allocated memory.  Intel has implemented a
> workaround, but it would require Dell to implement one
> of Intel’s latest VBIOS drops in there systems BIOS
> and then update the system BIOS.  I would expect any
> 855 release of system BIOS from Dell in the next 2
> months to have the VBIOS that allows the Xserver to
> report memory it allocated to the VBIOS and the modes
> could be adjusted.
> 
> Best regards,
> 
> Hope Merritt, III
> Intel Corporation
> Software Applications Engineer
> Desk: 916-356-0936
> Text: [EMAIL PROTECTED]
> 

__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: Dell C400 fix applied to 855GM?

[Alex Deucher]

well, yeah.  

My point was that intel should just release a patch to fix the driver
(or specs to let us fix it) rather than "fixing" the bios and making us
wait for dell to (possibly) update the bios.

Alex

--- "Mike A. Harris" <[EMAIL PROTECTED]> wrote:

> 
> Simple.  Because the Windows drivers have workarounds built into 
> them which manually program the chipset to do what the BIOS 
> should, but is not doing.  Why do they just work in Windows?  
> Because 95% of the desktop market is Windows, and the various 
> companies involved have a lot of money tied up in making sure 
> things just work the first time they hit the public eye the 
> majority of time.  As such problems like this are fixed in 
> Windows-land long before end users ever realize there was a 
> problem that needed to be fixed.
> 
> In the land of OSS however, we do not have that same status.  We 
> get specifications for hardware long after the fact if ever from 
> the majority of video hardware companies, and when someone 
> releases hardware with a broken BIOS that needs software driver 
> workarounds, someone needs to know what the exact problem is, and 
> then also have access to the specifications to know how to code 
> those workarounds, and also have the hardware in question in 
> order to test it.
> 
> So it is no surprise that what works in Windows is not any form 
> of indicator of what works in XFree86.  They are 2 different 
> environments, not privy to the same amount of technical 
> information as each other, and with very different number of 
> manpower working on each, and with IHV pressure also being quite 
> different for each.
> 
> 
> 
> -- 
> Mike A. Harris
> 


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: MGA fixes don't compile

[Alex Deucher]

it's also needed for mergedfb support on mga, although it could
probably be rewritten to not use HAL.

Alex

--- Dr Andrew C Aitchison <[EMAIL PROTECTED]> wrote:
> On Tue, 1 Jul 2003, Egbert Eich wrote:
> 
> > Dr Andrew C Aitchison writes:
> >  > 
> >  >  260. Disabled mode writeback to client program from MGA driver
> (Egbert 
> >  > Eich).
> >  > 
> >  > This doesn't compile on RedHat 6.2 / egcs-2.91.66
> >  > 
> > 
> > Hi Andrew,
> > 
> > Yes, thanks!
> > Mattieu already told me. 
> > It builds with gcc 3.3 (however issues warnings). I'll 
> > commit a little different fix later.
> > I have been thinking to remove the Matrox HAL stuff completely
> > and tell Matrox to ship this stuff in their binary only driver.
> > 
> > I had to program around so many things in the HALlib.
> > Furthermore using our driver with this lib is quite rediculous.
> > 
> > This lib does allmost all initialization. Only the hw cursor, dri
> > and accel functions are taken from our driver. 
> 
> I'd be very unhappy to lose the HAL;
> it helps a lot when getting a G550 to work with DVI monitors.
> Some monitors work without it, but others just don't seem to work
> unless I use mga_hal_drv.o
> 
> I believe that the /tmp/mgaDriverIn/Out stuff is only used by the
> MGA PowerDesktop, and I can live without that, but please don't
> remove 
> the HAL.
> 
> -- 
> Dr. Andrew C. Aitchison   Computer Officer, DPMMS, Cambridge
> [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna
> 
> 
> ___
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: MGA fixes don't compile

[Alex Deucher]

--- Egbert Eich <[EMAIL PROTECTED]> wrote:
> 
> The truth is that we don't know what MGA HAL does exactly.
> It does a lot of initialization stuff when it is called in
> PreInit()(!)
> and it sets up video modes differently than the OpenSource code does.
> In some cases it does the wrong thing so I had to add a lot of
> workarounds. In some other cases it does a better job - for example
> when setting up a video mode for flat panels.
> We could try to make the OpenSource driver better so we didn't have
> to use the HAL library any more - this however isn't really feasable
> without detailed docs on the chipsets and I don't think anybody is
> into register dumping and comparing.
> 

Actually you could probably replace the HAL functionality by using the
linux matrox framebuffer driver or directfb driver as a reference.  it
exposes just about all the functionality of the Gxxx driver (tv out,
flatpanel, YUV modes on the second crtc).

Alex


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: Xinerama on GeForce4 cards?

[Alex Deucher]

the nv driver does not support dualhead.  you need the nvidia binary.
Currently only mga, radeon, chips, and sis support dualhead on a single
card.

Alex

--- Kendall Bennett <[EMAIL PROTECTED]> wrote:
> Hi Guys!
> 
> We are trying to figure out how to get Dual Head working on the
> NVIDIA NV 
> driver that is included in XFree86. From looking at the code, it
> would 
> appear dual head mode is supposed to work; is that correct? If so,
> what 
> graphics chipsets should it work on? We have figured out how to
> configure 
> the XF86Config file to enable Xinerama on a Matrox G450 (with the
> help of 
> SuSE's SaX2), however using the same basic config file for the
> GeForce4 
> MX440, XFree86 fails to start with the error message "Requested
> entity 
> already in use!".
> 
> We are going to try the binary NVIDIA driver to see if that performs
> any 
> differently, but perhaps we are configuring XFree86 incorrectly for
> this 
> card? If dual head does work, can someone send me a working
> XF86Config 
> file for 4.3.0 that enables Xinerama on the GeForce4 MX440?
> 
> Thanks!
> 
> ---
> Kendall Bennett
> Chief Executive Officer
> SciTech Software, Inc.
> Phone: (530) 894 8400
> http://www.scitechsoft.com
> 
> ~ SciTech SNAP - The future of device driver technology! ~
> 


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: Xinerama on GeForce4 cards?

[Alex Deucher]

I don't suppose you can contribute your code back?  I've sure someone
could get it working in due time.

Alex

--- Kendall Bennett <[EMAIL PROTECTED]> wrote:
> Mark Vojkovich <[EMAIL PROTECTED]> wrote:
> 
> > > We are trying to figure out how to get Dual Head working on the
> NVIDIA NV 
> > > driver that is included in XFree86. From looking at the code, it
> would 
> > > appear dual head mode is supposed to work; is that correct? 
> > 
> > Not at all.  It only supports one head.  While the driver can
> > be configured to use one or the other, it will only work on the
> > head that was posted because it relies on the BIOS to do much of
> > the HW setup. 
> 
> Ok. Our code is actually working with dual head on the NVIDIA cards 
> provided that the BIOS has posted both heads to run in clone mode. On
> 
> some cards the BIOS does not post the second head and only one head
> comes 
> up, and the riva_hw.c module is not able to initialise the second
> head. I 
> guess we are stuck in that case ;-)
> 
> Regards,
> 
> ---
> Kendall Bennett
> Chief Executive Officer
> SciTech Software, Inc.
> Phone: (530) 894 8400
> http://www.scitechsoft.com
> 
> ~ SciTech SNAP - The future of device driver technology! ~
> 
> ___
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: MGA fixes don't compile

[Alex Deucher]

I believe someone asked Petr once and he said he didn't mind if we used
his driver as a reference.  IANAL, but as long as you didn't just
blatantly cut and paste the code, couldn't you use it as a reference? 
Still, probably better to get Petr's (and possibly directfb's) ok.

Alex

--- Andrew C Aitchison <[EMAIL PROTECTED]> wrote:
> On Wed, 2 Jul 2003, Alex Deucher wrote:
> 
> > Actually you could probably replace the HAL functionality by using
> the
> > linux matrox framebuffer driver or directfb driver as a reference. 
> it
> > exposes just about all the functionality of the Gxxx driver (tv
> out,
> > flatpanel, YUV modes on the second crtc).
> 
> Are we allowed to go grabbing chunks of code from those drivers ?
> 
> I've never looked at them because I've been afraid that if I did
> pinch code, we could end up with a court case.
> Problem is we would be taking code with a GNU copyright and
> presenting it with an XFree86 copyright.
> 
> Since I've never been taught how to do clean-room development,
> and don't have any guidelines, I'd rather not go reading the matroxfb
> code.
> 
> -- 
> Andrew C Aitchison
> 
> 
> ___
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: News about 3D..

[Alex Deucher]

right now? not likely.  Sis refuses to release the necessary databooks
needed to write a 3D driver.  unless this changes, we'll probably be
out of luck.

Alex

--- Serdar Cevher <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> I would like to know when SiS650 users could have the 3D support for
> the
> card on Linux. I hope you work on it.
> 
> Serdar Cevher
> 


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: S3 Trio64UV+, S3 Trio64V2/DX

[Alex Deucher]

open a bug at http://bugs.xfree86.org/ and include your patch so that
it doesn't get lost.  hopefully it will get fixed up and integrated.

Alex

--- áÌÅËÓÅÊ_âÁÊ <[EMAIL PROTECTED]> wrote:
> With the attached trivial patch I forced these cards to work to some
> extent
> with XFree 4.3.0 ...
> 
> Only 8,16 bit depths work.
> 64V2/DX may be needed slow_dram_refresh option.
> 
> diff -u s3.bak/s3_driver.c s3/s3_driver.c
> --- s3.bak/s3_driver.c2003-02-27 22:59:43 +0200
> +++ s3/s3_driver.c2003-07-02 18:24:02 +0300
> @@ -127,11 +127,13 @@
>  
>  /* supported chipsets */
>  static SymTabRec S3Chipsets[] = {
> -{ PCI_CHIP_964_0,"964-0"},
> -{ PCI_CHIP_964_1,"964-1"},
> -{ PCI_CHIP_968,"968" },
> -{ PCI_CHIP_TRIO, "Trio32/64" },
> -{ PCI_CHIP_AURORA64VP,"Aurora64V+" },
> +{ PCI_CHIP_964_0,"964-0"},
> +{ PCI_CHIP_964_1,"964-1"},
> +{ PCI_CHIP_968,"968" },
> +{ PCI_CHIP_TRIO, "Trio32/64" },
> +{ PCI_CHIP_AURORA64VP,"Aurora64V+" },
> +{ PCI_CHIP_TRIO64UVP, "Trio64UV+" },
> +{ PCI_CHIP_TRIO64V2_DXGX,"Trio64V2/DX/GX" },
>  { -1, NULL }
>  };
>  
> @@ -142,6 +144,8 @@
>  { PCI_CHIP_968, PCI_CHIP_968, RES_SHARED_VGA },
>  { PCI_CHIP_TRIO, PCI_CHIP_TRIO, RES_SHARED_VGA },
>  { PCI_CHIP_AURORA64VP,PCI_CHIP_AURORA64VP,
> RES_SHARED_VGA },
> +{ PCI_CHIP_TRIO64UVP,PCI_CHIP_TRIO64UVP, RES_SHARED_VGA
> },
> +{ PCI_CHIP_TRIO64V2_DXGX,PCI_CHIP_TRIO64V2_DXGX,
>  RES_SHARED_VGA },
>  { -1,-1,  RES_UNDEFINED }
>  };
>  
> @@ -531,6 +535,8 @@
>  case PCI_CHIP_AURORA64VP:/* ??? */
>  pS3->S3NewMMIO = FALSE;
>  break;
> +case PCI_CHIP_TRIO64V2_DXGX:
> +case PCI_CHIP_TRIO64UVP:
>  case PCI_CHIP_968:
>  pS3->S3NewMMIO = TRUE;
>  break;
> @@ -580,6 +586,15 @@
>  outb(0x102, 0x01);
>  outb(0x46e8, 0x08);
>  
> +if (pS3->Chipset == PCI_CHIP_TRIO64V2_DXGX)
> +{
> +  outb (0x3d4, 0x86);
> +  outb (0x3d5, 0x80);
> +  
> +  outb (0x3d4, 0x90);
> +  outb (0x3d5, 0x00);
> +}
> +
>  if (!pScrn->videoRam) {
>  /* probe videoram */
>  outb(vgaCRIndex, 0x36);
> @@ -1118,7 +1133,9 @@
>  
>  if (pS3->Chipset == PCI_CHIP_968)
>  shift = 1;/* XXX IBMRGB */
> -else if (pS3->Chipset == PCI_CHIP_TRIO)
> +else if (pS3->Chipset == PCI_CHIP_TRIO ||
> + pS3->Chipset == PCI_CHIP_TRIO64UVP ||
> + pS3->Chipset == PCI_CHIP_TRIO64V2_DXGX)
>  shift = -(pS3->s3Bpp >> 1);
>  
>  return shift;
> diff -u s3.bak/s3.h s3/s3.h
> --- s3.bak/s3.h2002-12-11 19:30:47 +0200
> +++ s3/s3.h2003-06-27 12:40:22 +0300
> @@ -240,6 +240,8 @@
>  #define S3_964_SERIES()((pS3->Chipset == PCI_CHIP_964_0) || 
>   \
>(pS3->Chipset == PCI_CHIP_964_1))
>  #defineS3_TRIO_SERIES()((pS3->Chipset == PCI_CHIP_TRIO) ||  
>  \
> -  (pS3->Chipset == PCI_CHIP_AURORA64VP))
> +  (pS3->Chipset == PCI_CHIP_AURORA64VP) || \
> + (pS3->Chipset == PCI_CHIP_TRIO64UVP) || \
> + (pS3->Chipset == PCI_CHIP_TRIO64V2_DXGX))
>  
>  #endif /* _S3_H */
> diff -u s3.bak/s3_Trio64DAC.c s3/s3_Trio64DAC.c
> --- s3.bak/s3_Trio64DAC.c2003-02-27 22:59:43 +0200
> +++ s3/s3_Trio64DAC.c2003-07-02 17:40:30 +0300
> @@ -324,9 +324,13 @@
>  if (pS3->Chipset == PCI_CHIP_AURORA64VP)
>  S3TrioSetClock(pScrn, mode->Clock, 2, 1, 1, 63, 0, 3, 2,
> 135000, 27);
> +else if (pS3->Chipset == PCI_CHIP_TRIO64V2_DXGX)
> +S3TrioSetClock(pScrn, mode->Clock, 2, 1, 1, 31, 0, 3, 2,
> +   17, 27);
>  else
>  S3TrioSetClock(pScrn, mode->Clock, 2, 1, 1, 31, 0, 3, 2,
> 135000, 27);
> +
>  
>  outb(0x3c4, 1);
>  blank = inb(0x3c5);
> @@ -347,6 +351,11 @@
>  sr18 = inb(0x3c5) & ~0x80;
>  outb(pS3->vgaCRIndex, 0x33);
>  cr33 = inb(pS3->vgaCRReg) & ~0x28;
> +
> +if (pS3->Chipset == PCI_CHIP_TRIO64V2_DXGX)
> +{
> +  cr33 |= 0x20;
> +}
>  
>  /* ! pixmux */
>  switch (pScrn->depth) {
> 
> 
> ___
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: XTest, Xinerama (Re: Xinerama, extensions, and x2x)

[Alex Deucher]

I believe this patch was already applied to cvs (HEAD, don't know about
the branches) a while back.

Alex

--- Erik van het Hof <[EMAIL PROTECTED]> wrote:
> Please find below an email and patch by Rik Faith to make XTEST work
> with Xinerama. I have backported this to a 4.2.1 version on my debian
> box and it worked. Could someone add this to cvs? it shouldn't be a
> lot of work.
> 
> Thanks
> Erik
> 


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel