Re: [Xpert]XVideo extension docs

[Guido Fiala]

On Wednesday, 24. July 2002 03:05, [EMAIL PROTECTED] wrote:
> > Thanks! That sounds really like i'am doing something wrong using repeated
> > calls of XvPutStill() every 40ms (PAL). So it would work to just call
> > XvPutVideo() once. I thought i made it right, as xawtv and mplayer both
> > do use Still. I tried just to use Video() but it did'nt display anything
> > at
>
> all.
>
> > Do you have sample code working as described?
>
> There is actually a simple program that does this included with xawtv.
> Download the xawtc src and look for a file called "rootv.c" in the src
> directory - that should do the trick.
>
> This will work with a brooktree (v4l) device provided the v4l module is
> loaded in the X server.  If you type xvinfo and get a device called
> "video4linux", you should be set.

Ok, i tryed it (once again):

$> ./rootv
4 adaptors available.
  name:  video4linux
  name:  video4linux
  name:  video4linux
  name:  3dfx Video Overlay

it prints and then stays quite. No video visible. Tested with the first 3 
ports ( 1 and 2 are dvb cards, 3 is bttv)
What wonders me, is that this program is there but xawtv uses XvShmPutStill() 
in it's Xv displaying loop anyway. Are you the only one able to use the 
PutVideo() call?

Which version of the bttv driver do i need at least?
(Still using 2.4.0 kernel)
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]adding radeon driver documentation

[hy0]

- Original Message -
From: "James Ralston" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, July 21, 2002 1:56 AM
Subject: [Xpert]adding radeon driver documentation

> Attached is the first draft.

Good to see the new Radeon man page being worked on.
I'll try to explain some of FIXMEs below.

> In particular, the following cards are known to work (FIXME: check list):
> ATI Radeon 8500 series
>   All-In-Wonder Radeon 8500
>   All-In-Wonder Radeon 8500DV
>   Radeon 8500 128MB
>   Radeon 8500 64MB
>   Radeon 8500LE
> ATI Radeon 7500 series
>   All-In-Wonder Radeon 7500
>   Radeon 7500
> ATI Radeon 7000 series
>   Radeon 7000 (also known as the Radeon VE)
> ATI Radeon series
>   Radeon All-In-Wonder
>   Radeon 64MB DDR (VIVO)
>   Radeon 64MB SDR
>   Radeon 32MB DDR
>   Radeon 32MB SDR
> ATI Radeon Mobility series
>   Radeon Mobility M6
>   Radeon Mobility M7

The supported chips (series) in the list are almost complete, except 7200
series (new version of old Radeon).
I'm not sure if we should list all memory+connector configurations here.
There are quite a few OEM versions of Radeon boards which may have different
configurations.


>  Note that the following cards are known not to work with the radeon
>  driver.  Support for these cards will be added in a future release of
XFree86 (FIXME: check both of these assertions):
> ATI Radeon 9700 series
> ATI Radeon 9000 series

These cards (also M9, using the same RV250 core as 9000) will be supported
(at least 2D part) in the near future.


> Note that not all monitors and not all Radeon cards support the VESA
> DDC/CI standard.  If DDCMode is enabled, but the monitor and/or card
> does not support the VESA DDC/CI standard, then XFree86 will emit a
> warning message and use the standard VESA mode timings instead.

All Radeon cards can do DDC probe, while some old CRTs or LCDs may not be
DDC capable.


> The advantage of not using DDCMode is that the VESA standard mode
> timings are supported by virtually all monitors.  Additionally, a monitor
which
> does not support the VESA standard mode timings will almost certainly not
> support the VESA DDC/CI standard.

The last statement is a bit confusing and may not be true. Traditionally,
the driver uses lookup-best-refresh routine looking for the best refresh
mode within standard VESA modes according to the specified VRefresh/HSync
ranges. It should work well for most of displays.

> The advantage of using DDCMode is that your particular monitor may
> support non-standard non-VESA) mode timings which are better (e.g., a
> higher refresh rate) than the VESA standard mode timings.  Additionally,
> for flat panel displays being used in analog mode, DDCMode will avoid
using
> unstable modes (some VESA standard modes don't really work with these
> panels).

This is okay.

> VideoKey Option
> This Option can be used to override the default video key value
> (FIXME: what does the video key do?  Why would one want to override
> the default value?)

VideoKey (aka colorkey) color is used by hardware overlay for displaying.
The hardware overlay image is only visible on the colorkey color. When an
application (like gtv) calls into driver for displaying a frame of video,
the driver will paint the background of the application window to the
colorkey color so that the hardware overlay can display on it. When another
window overlaps on top of the video window, the overlay (video image) will
be covered as long as the colors in the overlapped window do not match the
colorkey color. If one color in the overlapped window matches the colorkey
color, that part of window will appear to be transparent (you can see thru
it to the underneath video image). To avoid this, you can specify an
uncommon color to your system as the colorkey.


> The following Options are designed for Radeon cards with multiple video
ports, 
> Specifying these Options for cards without multiple video ports will have
no
> effect.  (FIXME: is this true?)

True.

> The Options are:
> Option CloneDisplay  boolean
> If set to true, then the DVI port will be cloned onto the CRT port.  The
> default is false (meaning, the DVI port will not be cloned onto the CRT
port).

This option may be set to default on in future after more tests.
All clone mode stuffs shouldn't have any effect if only one monitor
connected or if there are two Screen sections.

> FIXME: the "Here is a hack for cloning first display on the second
> head" comments in radeon_driver.c (in the RADEONPreInitModes function)
> seem to imply that if both the DVI and CRT ports are being used, and
> both have displays connected to them, and only one screen is defined
> in XF86Config, and CloneDisplay isn't being used, then the monitor
> connected to the CRT port will be driven according to the capability
> of the monitor/panel connected to the DVI port.  But the "VE and M6
> have both DVI and CRT ports" comments (in the
> RADEONGetBIOSParameters function) seem to imply that if both
> the DVI and CR

[Xpert]Re: nvidia binary driver: kernel BUG at page_alloc.c

[Mike A. Harris]

On Tue, 23 Jul 2002, Mike Stilson wrote:

>Date: Tue, 23 Jul 2002 07:16:50 -0400
>From: Mike Stilson <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Content-Type: text/plain; charset=us-ascii
>List-Id: General X Discussion 
>Subject: Re: nvidia binary driver: kernel BUG at page_alloc.c
>
>On Mon, Jul 22, 2002 at 11:25:35PM +0200, Luca Olivetti wrote:
>>-BEGIN PGP SIGNED MESSAGE-
>>Hash: SHA1
>>
>>Mike Stilson wrote:
>>Are you sure the nvidia module was loaded at the time of this crash?
>>It would taint the kernel if loaded:
>>
>>Jul  7 20:20:54 pippo kernel: kernel BUG at page_alloc.c:216!
>>Jul  7 20:20:54 pippo kernel: invalid operand: 
>>Jul  7 20:20:54 pippo kernel: CPU:0
>>Jul  7 20:20:54 pippo kernel: EIP:0010:[rmqueue+479/544]Tainted: P
>>Jul  7 20:20:54 pippo kernel: EIP:0010:[]Tainted: P
>
>Just to follow up after giving a little more thought...
>The kernel module doesn't taint it since I'm recompiling it from source.
>the NVdriver.o module (although it doesn't specifically have a
>MODULE_LICENSE("GPL")) also doesn't have any conflicting or proprietary
>license.  Now my understanding might be wrong, but it SHOULDN'T be
>tainting the kernel.  Only the X driver (nvidia_drv.o) is closed source.
>
>Perhaps you have something else tainting it?

The Nvidia kernel module very much does and should taint the 
kernel.


-- 
Mike A. Harris  Shipping/mailing address:
OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie,
XFree86 maintainer  Ontario, Canada, P6C 5B3
Red Hat Inc.
http://www.redhat.com   ftp://people.redhat.com/mharris

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

[Xpert]Debugging server crash?

[Manuel McLure]

I'm getting server crashes with the latest CVS build. I have attached a
server log, but unfortunately I am not seeing any cores left around to
debug this with. Any ideas on how I can try to get more information to
debug this?

This usually seems to happen when a OpenGL screensaver is running. I'm
on a Radeon 8500 128M.

-- 
Manuel A. McLure KE6TAW <[EMAIL PROTECTED]> 
...for in Ulthar, according to an ancient and significant law,
no man may kill a cat.   -- H.P. Lovecraft



This is a pre-release version of XFree86, and is not supported in any
way.  Bugs may be reported to [EMAIL PROTECTED] and patches submitted
to [EMAIL PROTECTED]  Before reporting bugs in pre-release versions,
please check the latest version in the XFree86 CVS repository
(http://www.XFree86.Org/cvs)

XFree86 Version 4.2.99.1 (Custom Build: 4.2.0-20020711_CVS) / X Window System
(protocol Version 11, revision 0, vendor release 6600)
Release Date: 7 June 2002
If the server is older than 6-12 months, or if your card is
newer than the above date, look for a newer version before
reporting problems.  (See http://www.XFree86.Org/)
Build Operating System: Linux 2.4.18-5-mppe i686 [ELF] 
Build Host: ulthar.internal.mclure.org
 
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
 (++) from command line, (!!) notice, (II) informational,
 (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/XFree86.0.log", Time: Tue Jul 23 19:34:46 2002
(==) Using config file: "/etc/X11/XF86Config-4"
(==) ServerLayout "XFree86 Configured"
(**) |-->Screen "Screen0" (0)
(**) |   |-->Monitor "NEC FE950+"
(**) |   |-->Device "ATI Radeon 8500"
(**) |-->Input Device "Mouse0"
(**) |-->Input Device "Keyboard0"
(**) Option "XkbLayout" "us"
(**) XKB: layout: "us"
(**) Option "XkbOptions" "ctrl:swapcaps"
(**) XKB: options: "ctrl:swapcaps"
(==) Keyboard: CustomKeycode disabled
(**) FontPath set to "unix/:7100"
(==) RgbPath set to "/usr/X11R6/lib/X11/rgb"
(==) ModulePath set to "/usr/X11R6/lib/modules"
(--) using VT number 7

(II) Open APM successful
(II) Module ABI versions:
XFree86 ANSI C Emulation: 0.1
XFree86 Video Driver: 0.6
XFree86 XInput driver : 0.3
XFree86 Server Extension : 0.1
XFree86 Font Renderer : 0.3
(II) Loader running on linux
(II) LoadModule: "bitmap"
(II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a
(II) Module bitmap: vendor="The XFree86 Project"
compiled for 4.2.99.1, module version = 1.0.0
Module class: XFree86 Font Renderer
ABI class: XFree86 Font Renderer, version 0.3
(II) Loading font Bitmap
(II) LoadModule: "pcidata"
(II) Loading /usr/X11R6/lib/modules/libpcidata.a
(II) Module pcidata: vendor="The XFree86 Project"
compiled for 4.2.99.1, module version = 0.1.0
ABI class: XFree86 Video Driver, version 0.6
(II) PCI: Probing config type using method 1
(II) PCI: Config type is 1
(II) PCI: stages = 0x03, oldVal1 = 0x8048, mode1Res1 = 0x8000
(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:00:0: chip 1022,700e card , rev 13 class 06,00,00 hdr 00
(II) PCI: 00:01:0: chip 1022,700f card , rev 00 class 06,04,00 hdr 01
(II) PCI: 00:07:0: chip 1106,0686 card 147b,a702 rev 40 class 06,01,00 hdr 80
(II) PCI: 00:07:1: chip 1106,0571 card 1106,0571 rev 06 class 01,01,8a hdr 00
(II) PCI: 00:07:2: chip 1106,3038 card 0925,1234 rev 1a class 0c,03,00 hdr 00
(II) PCI: 00:07:3: chip 1106,3038 card 0925,1234 rev 1a class 0c,03,00 hdr 00
(II) PCI: 00:07:4: chip 1106,3057 card 1106,3057 rev 40 class 0c,05,00 hdr 00
(II) PCI: 00:09:0: chip 1013,6003 card 1681,0050 rev 01 class 04,01,00 hdr 00
(II) PCI: 00:0b:0: chip 1317,0985 card 1317,0574 rev 11 class 02,00,00 hdr 00
(II) PCI: 00:0d:0: chip 10cd,1300 card 10cd,1310 rev 03 class 01,00,00 hdr 00
(II) PCI: 00:0f:0: chip 104c,8019 card 11bd,000e rev 00 class 0c,00,10 hdr 00
(II) PCI: 01:05:0: chip 1002,514c card 1002,013a rev 00 class 03,00,00 hdr 00
(II) PCI: End of PCI scan
(II) LoadModule: "scanpci"
(II) Loading /usr/X11R6/lib/modules/libscanpci.a
(II) Module scanpci: vendor="The XFree86 Project"
compiled for 4.2.99.1, module version = 0.1.0
ABI class: XFree86 Video Driver, version 0.6
(II) UnloadModule: "scanpci"
(II) Unloading /usr/X11R6/lib/modules/libscanpci.a
(II) Host-to-PCI bridge:
(II) Bus 0: bridge is at (0:0:0), (-1,0,0), BCTRL: 0x08 (VGA_EN is set)
(II) Bus 0 I/O range:
[0] -1  0   0x - 0x (0x1) IX[B]
(II) Bus 0 non-prefetchable memory range:
[0] -1  0   0x - 0x (0x0) MX[B]
(II) Bus 0 prefetchable memory range:
[0] -1  0   0x - 0x (0x0) MX[B]
(II) PCI-to-PCI bridge:
(II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x0e (VGA_EN is set)
(II) Bus 1 I/O range:
[0] -1  0   0xc000 - 0xc0ff (0x100) IX[B]
[1] -1  0   0xc

[Xpert]Opengl program performance drops after upgrading to XFree86 4.2

[Jason Hu Huang]

Thanks Michel,

The DRI is not enabled. However I have tried all the methods that I can figure 
out to enable it with no luck.
I am using ATI radeon VE.
I have loaded the glx and dri modules and the device type is set "ati" in the 
XF86Config-4, but in the log file, the dri is not disabled.
I dont know why, can anyone help?




-
This mail sent through IMP: http://horde.org/imp/
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

[Xpert]porting X420 to our new machine

[xjj]

hi all,
 I want to port X420 to our new machine with new architecture and new assembler 
language. The video we selected is sis305. 
 which configuration would I choose, XKdrive+vesa, XKdrive+fb,XKdrive+sis305,or 
XFree86+vesa, XFree86+fb,XFree86+sis305?  Which requires the least porting job? And 
what should I do?
 Thx for any advice.

Best regards!
Xu Junjuan
Architecture Group, Depart. of CS, Peking Univ.
Tel: +86(010)62765828-882
[EMAIL PROTECTED] 
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]XVideo extension docs

[Billy Biggs]

Michel Lanners ([EMAIL PROTECTED]):

> On  23 Jul, this message from Guido Fiala echoed through cyberspace:
> >> moving YUV across the bus, but it should use no CPU.
> > 
> > Yes, so i thought. But that would mean, that the XServer loads it's
> > data directly from the v4l device itself (mmap-io or direct write
> > into AGP-memory?) The latter should work if the ximage is a
> > contigous array in AGP memory only.
> 
> No, it's the video input hardware that pushes the data with DMA to an
> off-screen VRAM memory area, and the graphic chip then copies and
> color-converts on the fly to the visible window.

  Wouldn't it be great if they were actually in sync so they wouldn't
tear, or so that we could handled interlaced streams better.

  The v4l-module architecture needs to be reworked.

-- 
Billy Biggs
[EMAIL PROTECTED]
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]Xserver won\'t recognize PCI card

[Michel Dänzer]

On Wed, 2002-07-24 at 00:33, Daniel Sheltraw wrote:

> It appears that, in the machine which is unable to function as 
> expected, there is a problem with the Xserver recognizing the PCI
> card despite the fact we have told it where on the bus to find the 
> card in the XF86Config-4 file. Also both cards are recognized by 
> Linux as indicated in /proc/pci and both cards do function.

The only idea I have is that the bus ID you specify isn't correct. A
common cause of confusion is that lspci shows hex numbers, but X takes
decimal. At any rate, the correct bus ID should be in the log in a line
like

(--) PCI:*(0:16:0) ATI Radeon Mobility M7 LW rev 0, Mem @ 0xb800/27,
0xb000/16, I/O @ 0x0400/8, BIOS @ 0xb002/17


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

[Xpert]Xserver won\'t recognize PCI card

[Daniel Sheltraw]

Hell XF86 xpert and newbie lists

I have been chasing the solution to a problem for a few days now
and I wondering if anyone can help. I have two machines with
identical hardware except for the motherboards. Each has an ATI
Xpert 98 (PCI) card and Radeon 7500 (AGP) card. We are controlling
the PCI card with the Xserver and the AGP card with custom code.

This all works fine on one machine but not the other. Both
are running Redhat 7.2 and Kernel 2.4.14. We add an entry in
the XF86Config-4 file for the PCI card only and then must
re-enable the AGP card (since X disables it) through the PCI-config
space COMMAND register for our custom app. We give the bus, device
and function numbers explictly in the XF86Config-4 file on both
machines. 

But only the one machine is functioning as expected.
It appears that, in the machine which is unable to function as 
expected, there is a problem with the Xserver recognizing the PCI
card despite the fact we have told it where on the bus to find the 
card in the XF86Config-4 file. Also both cards are recognized by 
Linux as indicated in /proc/pci and both cards do function.

Any ideas why we are not able to get the Xserver to see our PCI
card on that one machine? Incidentally the machine that is having
trouble is one with a Supermicro P6SBA motherboard with 440BX chipset.



___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

[Xpert]Re: Radeon switch to VT and back X freeze POSSIBLE FIX

[Michel Dänzer]

On Tue, 2002-07-23 at 22:10, Charl P. Botha wrote:
> On Tue, Jul 23, 2002 at 12:55:00PM -0700, Kevin Oberman wrote:
> > Excuse the interruption, but I have been having a problem with an IBM
> > T30 with a Radeon Mobility M7 LW (LCD) losing sync after the display is
> > either turned off by either APM or via a Fn-F3. The failure is
> > intermittent, but frequent.
> > 
> > Is is remotely possible that this bus mastering issue could also be
> > causing my problem? If so, I'll look at trying your patch. This might
> > be slightly complicated since I am running FreeBSD, not Linux, but
> > probably not.
> 
> It doesn't _sound_ related.  The symptoms of loss of bus-mastering with the
> radeon drivers is that X sits at 100% CPU waiting for a card to go idle that
> never does...

Yes. Ironically, it never goes idle because it can never get busy in the
first place...

> the machine is reachable by network, but the console is dead.

I wonder what would happen if one enabled bus mastering when it's
'locked up', but that's purely academic. :)


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]XVideo extension docs

[Mark Vojkovich]

On Tue, 23 Jul 2002, Guido Fiala wrote:

> > I'm not sure if someone said this already or not, but the XvPutVideo simply
> > displays incoming analog video into the drawable specified in the
> > XvPutVideo call (some setup and configuration calls are req'd previous to
> > calling XvPutVideo() ).
> 
> Thanks! That sounds really like i'am doing something wrong using repeated 
> calls of XvPutStill() every 40ms (PAL). So it would work to just call 
> XvPutVideo() once. I thought i made it right, as xawtv and mplayer both do
> use Still. I tried just to use Video() but it did'nt display anything at all.
> 
> Do you have sample code working as described?
> 
> > moving YUV across the bus, but it should use no CPU.
> 
> Yes, so i thought. But that would mean, that the XServer loads it's data 
> directly from the v4l device itself (mmap-io or direct write into AGP-memory?)
> The latter should work if the ximage is a contigous array in AGP memory only.
> 
> > All-in-Wonder Radeon 8500 DV with the GATOS drivers.  Also, if you load the
> > v4l module in your XF86Config-4, you will be able to use the XvPutVideo
> 
> I did load the module and hence xvinfo prints out information on XvPutVideo() 
> but still no result.
> 
> > call on a video4linux device installed in your machine.  If anyone knows of
> 
> I tested it with bttv and dvb cards, botht did'nt work as expected, just with 
> XvPutStill()
> 
> (The v4l-dvb drivers are available at linuxtv.org, maybe someone can find a 
> hint in the driver itself)
> 
> Can it be, that whether V3K (or VxK) nor Matrox nor NVIDIA can do this?
> 

   The V4L module in XFree86 coordinates with V4L in the kernel to
have the video data dumped directly to the framebuffer.  In the most
simple case it dumps RGB data into the visible framebuffer.  Pretty
much all XFree86 cards should support that.  In the case of some
drivers (NVIDIA and Matrox and others) V4L is told to dump the
video to offscreen video ram and then the graphics card driver 
overlays it with HW scaling and filtering.  When you call XvPutVideo
it puts data from an XvPort (the TV card's output in this case) into
a window.  The server automatically handles cliplist changes, 
obscured windows, etc...  There should be little if any CPU 
involvement.


Mark.


___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

[Xpert]Xnest blocks when running remote StarOffice, and local Xinerama

[pcpa]

  Hi,

  When running "Xnest -query ", logging in, and starting soffice,
it will hang if the local xserver is using Xinerama. It seens that the
Xnest is not (always) receiving back the expected order of events after a
XCopyArea, and blocking in the XIfEvent call. Whit this patch, that is only
useful to not let it block forever, it will print the error message, always
with the event 14 (NoExpose), because the call to XCheckIfEvent returned
too early...

  I just wrote this patch to Xnest:
--%<--
Index: Events.c
===
RCS file: /home/x-cvs/xc/programs/Xserver/hw/xnest/Events.c,v
retrieving revision 1.2
diff -u -u -r1.2 Events.c
--- Events.c2001/08/01 00:44:57 1.2
+++ Events.c2002/07/23 20:51:47
@@ -187,7 +187,7 @@
   break;
   
 default:
-  ErrorF("xnest warning: unhandled event\n");
+  ErrorF("xnest warning: unhandled event %d\n", X.type);
   break;
 }
   }
Index: GCOps.c
===
RCS file: /home/x-cvs/xc/programs/Xserver/hw/xnest/GCOps.c,v
retrieving revision 3.4
diff -u -u -r3.4 GCOps.c
--- GCOps.c 2001/01/17 22:36:55 3.4
+++ GCOps.c 2002/07/23 20:51:48
@@ -157,8 +157,8 @@
 if(!pReg || !pTmpReg) return NullRegion;
 
 pending = True;
-while (pending) {
-  XIfEvent(xnestDisplay, &event, xnestBitBlitPredicate, NULL);
+while (pending &&
+  XCheckIfEvent(xnestDisplay, &event, xnestBitBlitPredicate, NULL)) {
   
   switch (event.type) {
   case NoExpose:
--%<--


Paulo
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]XVideo extension docs

[Michel Lanners]

On  23 Jul, this message from Guido Fiala echoed through cyberspace:
>> moving YUV across the bus, but it should use no CPU.
> 
> Yes, so i thought. But that would mean, that the XServer loads it's data 
> directly from the v4l device itself (mmap-io or direct write into AGP-memory?)
> The latter should work if the ximage is a contigous array in AGP memory only.

No, it's the video input hardware that pushes the data with DMA to an
off-screen VRAM memory area, and the graphic chip then copies and
color-converts on the fly to the visible window.

Cheers

Michel

-
Michel Lanners |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes|Ask Questions.  Make Mistakes.
L-1710 Luxembourg  |
email   [EMAIL PROTECTED]|
http://www.cpu.lu/~mlan| Learn Always. "

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]XVideo extension docs

[Mark Cuss]

- Original Message - >
> Thanks! That sounds really like i'am doing something wrong using repeated
> calls of XvPutStill() every 40ms (PAL). So it would work to just call
> XvPutVideo() once. I thought i made it right, as xawtv and mplayer both do
> use Still. I tried just to use Video() but it did'nt display anything at
all.
>
> Do you have sample code working as described?

There is actually a simple program that does this included with xawtv.
Download the xawtc src and look for a file called "rootv.c" in the src
directory - that should do the trick.

This will work with a brooktree (v4l) device provided the v4l module is
loaded in the X server.  If you type xvinfo and get a device called
"video4linux", you should be set.

Mark



___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

[Xpert]Re: [Dri-devel] Radeon switch to VT and back X freeze POSSIBLE FIX

[Charl P. Botha]

On Tue, Jul 23, 2002 at 08:57:29PM +0200, Charl P. Botha wrote:
> Which patch are you using?  The one I sent, or the one Michel committed?  I
> am concerned (and Michel, correct me if I'm blundering) that the DRI commit
> has the bus master enable AFTER RADEONEngineRestore().

I've tested with Michel's DRI commit and it's rock-solid.  I can NOT make
the machine crash by VT switching, no matter how many times I switch to VT
and back.  I even did the hitherto unthinkable (with this Radeon) and
switched with a Viewperf 6.1.2 benchmark running.

More testing anyone?

Happiness,
Charl

Ps. Now on to making agpgart + dri work with swsusp, which was the whole
point of this exercise.

-- 
charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]Re: [Dri-devel] Radeon switch to VT and back X freeze POSSIBLE FIX

[Charl P. Botha]

On Tue, Jul 23, 2002 at 12:55:00PM -0700, Kevin Oberman wrote:
> Excuse the interruption, but I have been having a problem with an IBM
> T30 with a Radeon Mobility M7 LW (LCD) losing sync after the display is
> either turned off by either APM or via a Fn-F3. The failure is
> intermittent, but frequent.
> 
> Is is remotely possible that this bus mastering issue could also be
> causing my problem? If so, I'll look at trying your patch. This might
> be slightly complicated since I am running FreeBSD, not Linux, but
> probably not.

It doesn't _sound_ related.  The symptoms of loss of bus-mastering with the
radeon drivers is that X sits at 100% CPU waiting for a card to go idle that
never does... the machine is reachable by network, but the console is dead.

-- 
charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]nvidia binary driver: kernel BUG at page_alloc.c

[Mike Stilson]

On Tue, Jul 23, 2002 at 01:36:39PM +0200, Charl P. Botha wrote:
>On Tue, Jul 23, 2002 at 07:16:50AM -0400, Mike Stilson wrote:
>> Just to follow up after giving a little more thought...
>> The kernel module doesn't taint it since I'm recompiling it from source.
>> the NVdriver.o module (although it doesn't specifically have a
>> MODULE_LICENSE("GPL")) also doesn't have any conflicting or proprietary
>> license.  Now my understanding might be wrong, but it SHOULDN'T be
>> tainting the kernel.  Only the X driver (nvidia_drv.o) is closed source.
>
>The kernel module *does* taint it.  You're only building three of the
>objects and then linking with "Module-nvkernel", which is binary and which
>is where most of the juicy bits are.

Ok, that being the case, any idea as to why it's not tainted?  The
module is remaining loaded.

-- 
Windows has detected that you have moved your mouse.
Your system must now be restarted for the changes to take effect.
- Unknown
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]Re: [Dri-devel] Radeon switch to VT and back X freeze POSSIBLE FIX

[Kevin Oberman]

Excuse the interruption, but I have been having a problem with an IBM
T30 with a Radeon Mobility M7 LW (LCD) losing sync after the display is
either turned off by either APM or via a Fn-F3. The failure is
intermittent, but frequent.

Is is remotely possible that this bus mastering issue could also be
causing my problem? If so, I'll look at trying your patch. This might
be slightly complicated since I am running FreeBSD, not Linux, but
probably not.

R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED]  Phone: +1 510 486-8634
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]XVideo extension docs

[Dean S. Messing]

 :: 
 :: > I'm not quite sure what YUV2 is but ordinary MPEG2 YUV (more properly,
 :: > Y, Cb, Cr) is such that U and V are subsampled x2 horizontally w.r.t. Y and
 :: > that is how you get "16 bits".
 :: 
 :: I'am far from xpert at this area - so maybe i'am wrong at this ml anyway 
 :: mayself ;-)

I'm an image/signal processing researcher.  As I've demonstrated several
times on this list, I know next to nothing about X,  itself, except as
a simple user who wants to learn.  You're probably on the right list.
But the real xperts would be a better judge of that.

 :: > Bit chopping does not, technically speaking, result in loss of resolution.
 :: > Instead you get various "contouring" and other artifacts due to the
 :: 
 :: Exactly that is what i see!
 :: 
 :: But what to do now? Is there a way to support more ximage input formats?

This is a question for the Xperts.  I can't help you.  I can only explain
why you see what you see :-)

 :: But, this is going OT now - as it was about Xvideo docs. Still got no 
 :: detailed explanation why i should use the XvPutVideo() function call at all, 
 :: which i thought would solve btw, the problem of the high CPU-load (at least 
 :: reported to me with V3K + NVIDIA + Matrox cards).

Comments from the Xperts?

Dean
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]XVideo extension docs

[Guido Fiala]

> I'm not sure if someone said this already or not, but the XvPutVideo simply
> displays incoming analog video into the drawable specified in the
> XvPutVideo call (some setup and configuration calls are req'd previous to
> calling XvPutVideo() ).

Thanks! That sounds really like i'am doing something wrong using repeated 
calls of XvPutStill() every 40ms (PAL). So it would work to just call 
XvPutVideo() once. I thought i made it right, as xawtv and mplayer both do
use Still. I tried just to use Video() but it did'nt display anything at all.

Do you have sample code working as described?

> moving YUV across the bus, but it should use no CPU.

Yes, so i thought. But that would mean, that the XServer loads it's data 
directly from the v4l device itself (mmap-io or direct write into AGP-memory?)
The latter should work if the ximage is a contigous array in AGP memory only.

> All-in-Wonder Radeon 8500 DV with the GATOS drivers.  Also, if you load the
> v4l module in your XF86Config-4, you will be able to use the XvPutVideo

I did load the module and hence xvinfo prints out information on XvPutVideo() 
but still no result.

> call on a video4linux device installed in your machine.  If anyone knows of

I tested it with bttv and dvb cards, botht did'nt work as expected, just with 
XvPutStill()

(The v4l-dvb drivers are available at linuxtv.org, maybe someone can find a 
hint in the driver itself)

Can it be, that whether V3K (or VxK) nor Matrox nor NVIDIA can do this?

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

[Xpert]Re: [Dri-devel] Radeon switch to VT and back X freeze POSSIBLE FIX

[Charl P. Botha]

On Tue, Jul 23, 2002 at 01:46:34PM -0500, Steven Walter wrote:
> On Tue, Jul 23, 2002 at 01:04:56PM -0500, Steven Walter wrote:
> > To summarize, this patch seems only the make the lock-ups less
> > reproducible.  Sometimes it takes 3, sometimes four, sometimes 2.  I
> > don't think I've gotten a lock on the first switch, yet.  I'm using the
> > radeonfb; I'll have to attempt without.
> > 
> > Additionally, I'd like to see what, if any, effect XVidMode has, as it
> > changed the situation before the fix.
> > 
> > However, using radeonfb and with XVidMode enable, the lock-up IS STILL
> > THERE.  But I have a feeling you are now much closer.
> 
> Okay, I have tried without xvidmode and without radeonfb, and the
> lockups still occur.  Additionally, I have induced the lock-up on the
> first VT switch.
> 
> Really, all this patch has accomplished for me is that sometimes, the
> patch occurs on the 3rd or 4th vt-switch, instead of reproducibly the
> first as before.
> 
> It was noted that this patch was tried on a machine that didn't
> experience the problem, and that nothing broke.  Has anyone actually
> tried the patch on a machine with the problem, and have the problem
> solved?  If not, it seems to me that this patch doesn't buy us all that
> much.

I have just tested on my laptop which had the problem (and which is why I
started spending time on this in the first time).  I've just done 13 VT
switches, with and without glxgears running and have not been able to induce
the crash.  I'm even getting tired of VT switching... ;)

Which patch are you using?  The one I sent, or the one Michel committed?  I
am concerned (and Michel, correct me if I'm blundering) that the DRI commit
has the bus master enable AFTER RADEONEngineRestore().

I am still interested to see the 3 lspci -vvv's, your XF86Config-4 and your
XFree86.log.

Thanks,
Char

-- 
charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

[Xpert]Re: [Dri-devel] Radeon switch to VT and back X freeze POSSIBLE FIX

[Charl P. Botha]

On Tue, Jul 23, 2002 at 01:04:56PM -0500, Steven Walter wrote:
> > So, appended is a patch that changes the RADEONEnterVT code in
> > radeon_driver.c so that it re-enables bus mastering mode.  Michel has tested
> > it on his TiBook (which doesn't have the problem) and the patch doesn't seem
> > to break anything.
> > 
> > Please apply to the DRI trunk and XFree86 CVS if you think this is
> > applicable.  If you can keep my name in the source, I'll be even happer.
> > Yes, small things amuse small minds. ;)
> 
> I have just tried your fix with a Radeon 7500 QW and have gotten some
> interesting, and perhaps hopeful, results.
> 
> To summarize, this patch seems only the make the lock-ups less
> reproducible.  Sometimes it takes 3, sometimes four, sometimes 2.  I
> don't think I've gotten a lock on the first switch, yet.  I'm using the
> radeonfb; I'll have to attempt without.
> 
> Additionally, I'd like to see what, if any, effect XVidMode has, as it
> changed the situation before the fix.
> 
> However, using radeonfb and with XVidMode enable, the lock-up IS STILL
> THERE.  But I have a feeling you are now much closer.

Hmm, can you do a lspci -vvv before and after the crash? (if you have a
machine from which you can ssh in to the crashed machine)  In addition, also
do a lspci -vvv just after you've switched to the VT.

Thanks,
Charl

-- 
charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

[Xpert]Re: [Dri-devel] Radeon switch to VT and back X freeze POSSIBLE FIX

[Charl P. Botha]

On Tue, Jul 23, 2002 at 06:33:27PM +0200, Benjamin Herrenschmidt wrote:
> >So, appended is a patch that changes the RADEONEnterVT code in
> >radeon_driver.c so that it re-enables bus mastering mode.  Michel has tested
> >it on his TiBook (which doesn't have the problem) and the patch doesn't seem
> >to break anything.
> >
> >Please apply to the DRI trunk and XFree86 CVS if you think this is
> >applicable.  If you can keep my name in the source, I'll be even happer.
> >Yes, small things amuse small minds. ;)
> 
> I don't think this is the proper fix. It's probably only a workaround.
> It stops the card from bus mastering, thus probably aborting any
> bus master transaction (so all ring operations), but that should
> _fix_ any problem unless the card is still doing something it
> shouldn't do at this point.
> 
> Actually, even if I know no fbdev driver doing so, those could well
> want bus mastering as well and might be confused by XFree disabling
> it.

The patch doesn't disable bus mastering, but ENABLES it when we return to X.
We still don't know why it gets disabled in the first place when switching
to a VT, as the X code does NOT disable bus mastering at all.  Our current
suspect is card/agp firmware.

-- 
charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]XVideo extension docs

[Mark Cuss]

> But, this is going OT now - as it was about Xvideo docs. Still got no
> detailed explanation why i should use the XvPutVideo() function call at
all,
> which i thought would solve btw, the problem of the high CPU-load (at
least
> reported to me with V3K + NVIDIA + Matrox cards).

I'm not sure if someone said this already or not, but the XvPutVideo simply
displays incoming analog video into the drawable specified in the XvPutVideo
call (some setup and configuration calls are req'd previous to calling
XvPutVideo() ).

If you wish to display "video in a window" on your linux box from an analog
source, like a camcorder, then this will work - I use it all the time.  It
should not load down your system - it will take a bit of PCI bandwidth
moving YUV across the bus, but it should use no CPU.

This call will only work on certain hardware, depending upon the drivers
available.  It does work on an ATI All-in-Wonder Radeon and ATI
All-in-Wonder Radeon 8500 DV with the GATOS drivers.  Also, if you load the
v4l module in your XF86Config-4, you will be able to use the XvPutVideo call
on a video4linux device installed in your machine.  If anyone knows of any
other hardware this works on, please let me know.

I'm not sure if that helped or not, but that's what XvPutVideo() does

Mark


___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]MotionNotify

[Mark Vojkovich]

On Tue, 23 Jul 2002, jeyasudha wrote:

> Hi Xperts,
> I want to get all the mouse move events.  I'm using all masks
> ButtonMotionMask 
> (for all 5 buttons), PointerMotionMask. Still my window is not getting
> the 
> MotionNotify events whenever i move the mouse. I read PointerMotionHint
> Mask 
> will reduce the motion events to one.  Hence i have not used it. 
> 
> Which is hogging my MotionNotify events? 
> 

  PointerMotionMask is sufficient to get MotionNotify events.
If you are not getting any events you probably have something
wrong in your program.


Mark.
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

[Xpert]Re: [Dri-devel] Radeon switch to VT and back X freeze POSSIBLE FIX

[Michel Dänzer]

On Tue, 2002-07-23 at 19:05, Charl P. Botha wrote:
> Dear list,
> 
> On Tue, Jul 16, 2002 at 11:02:05PM +0200, Charl P. Botha wrote:
> > This is just to add another sample to the Radeon switch to VT and back X
> > freeze bug, which is apparently known.
> 
> Michel Dänzer and I spent some more time on this bug today.  After having
> mucked around with some of the AGP settings (with no success), I did a pre-
> and post-crash "lspci -vvv".  The video card was leaving bus mastering mode
> when X switched to the console!  It seems this is the root of the VT
> switching bug, at least on my system.  At least this specific condition is
> easy to test for on the systems of users that experience this crash.
> 
> So, appended is a patch that changes the RADEONEnterVT code in
> radeon_driver.c so that it re-enables bus mastering mode.  Michel has tested
> it on his TiBook (which doesn't have the problem) and the patch doesn't seem
> to break anything.
> 
> Please apply to the DRI trunk and XFree86 CVS if you think this is
> applicable.

I've committed a slightly modified version to the DRI trunk. Thanks for
putting all the time and energy into tracking this down!

Now I wonder if the other drivers need the same; a recent r128 report
sounds similar, so I'll move it there as well, but what about the
others? Does anyone have an idea why bus mastering gets disabled?


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

[Xpert]Dual head with on board S3trio64 and PCI GVX1 card?

[John Gay]

I was playing with an old box and a PCI GVX1 card I have.

After building X4.2.0 from source, the first time I ran XF86Config it noticed 
that the box also has an S3trio64 on-board, but X crashed before I could set 
it up.

After that I had to resort to using XF86Config -textmode to configure it.

The problem I have is the S3trio64 reports no memory at all, hence, no valid 
modelines and no display. The GVX1 card is working fine.

Is it possible to get Dualhead working with this setup?

I've tried adding a VideoRam line to the device entry, but this does not seem 
to make any difference.

Any Ideas?

Cheers,

John Gay

johngay@debian:~$ cat XF86Config
Section "ServerLayout"
Identifier "Layout0"
Screen  0  "Screen0" 0 0
Screen  1  "Screen1" RightOf "Screen0"
InputDevice"Keyboard0" "CoreKeyboard"
InputDevice"Mouse0" "CorePointer"
EndSection

Section "Files"
EndSection

Section "Module"
Load  "xie"
Load  "pex5"
Load  "glx"
Load  "dri"
Load  "dbe"
Load  "record"
Load  "extmod"
Load  "type1"
EndSection

Section "InputDevice"
Identifier  "Mouse0"
Driver  "mouse"
Option  "Protocol" "PS/2"
Option  "Device" "/dev/psaux"
EndSection

Section "InputDevice"
Identifier  "Keyboard0"
Driver  "keyboard"
Option  "XkbModel" "pc104"
Option  "XkbLayout" "us"
EndSection

Section "Monitor"
Identifier   "Monitor0"
HorizSync31.5 - 42.5
VertRefresh  40.0 - 150.0
EndSection

Section "Monitor"
Identifier   "Monitor1"
HorizSync31.5 - 42.5
VertRefresh  40.0 - 150.0
EndSection

Section "Device"
#   ChipSet "pm3"
Identifier  "Card0"
Driver  "glint"
Card"3Dlabs pm3"
BusID   "PCI:0:13:0"
EndSection

Section "Device"
#   ChipSet "Trio32/64"
Identifier  "Card1"
Driver  "s3"
Card"S3 Trio32/64"
VideoRam4096
Option  "slow_vram" "on"
BusID   "PCI:0:16:0"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor"Monitor0"
DefaultDepth 24
SubSection "Display"
Depth 16
Modes"1152x864" "1024x768" "800x600" "640x480" "640x400" 
"512x384" "400x300" "320x240" "320x200"
EndSubSection
SubSection "Display"
Depth 24
Modes"1152x864" "1024x768" "800x600" "640x480" "640x400" 
"512x384" "400x300" "320x240" "320x200"
EndSubSection
SubSection "Display"
Depth 8
Black 0x 0x 0x
White 0x 0x 0x
Modes"1152x864" "1024x768" "800x600" "640x480" "640x400" 
"512x384" "400x300" "320x240" "320x200"
EndSubSection
EndSection

Section "Screen"
Identifier "Screen1"
Device "Card1"
Monitor"Monitor1"
DefaultDepth 24
SubSection "Display"
Depth 24
Modes"1280x960" "1152x864" "1024x768" "800x600" "640x480" 
"640x400" "512x384" "400x300" "320x240" "320x200"
EndSubSection
SubSection "Display"
Depth 16
Black 0x 0x 0x
White 0x 0x 0x
Modes"1280x960" "1152x864" "1024x768" "800x600" "640x480" 
"640x400" "512x384" "400x300" "320x240" "320x200"
EndSubSection
SubSection "Display"
Depth 8
Black 0x 0x 0x
White 0x 0x 0x
Modes"1280x960" "1152x864" "1024x768" "800x600" "640x480" 
"640x400" "512x384" "400x300" "320x240" "320x200"
EndSubSection
SubSection "Display"
Depth 4
Black 0x 0x 0x
White 0x 0x 0x
Modes"1280x960" "1152x864" "1024x768" "800x600" "640x480" 
"640x400" "512x384" "400x300" "320x240" "320x200"
EndSubSection
EndSection

johngay@debian:~$

johngay@debian:~$ cat XFree86.0.log

XFree86 Version 4.2.0 / X Window System
(protocol Version 11, revision 0, vendor release 6600)
Release Date: 18 January 2002
If the server is older than 6-12 months, or if your card is
newer than the above date, look for a newer version before
reporting problems.  (See http://www.XFree86.Org/)
Build Operating System: Linux 2.2.20 i586 [ELF]
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
 (++) from command line, (!!) notice, (II) informational,
 (WW) warning, (EE) error, (NI) not implemented, (??) unknown.(==) 
Log file: "/var/log/XFree86.0.log", Time: Sat Jul 20 21:29:00 2002
(==) Using config f

Re: [Xpert]XVideo extension docs

[Guido Fiala]

> I'm coming (butting?) into the middle of this so my comments
> may not be germane (in which case I won't be offended if you tell
> me to buzz off).

No, many thanks for your in depth explanation.

> I'm not quite sure what YUV2 is but ordinary MPEG2 YUV (more properly,
> Y, Cb, Cr) is such that U and V are subsampled x2 horizontally w.r.t. Y and
> that is how you get "16 bits".

I'am far from xpert at this area - so maybe i'am wrong at this ml anyway 
mayself ;-)

> Bit chopping does not, technically speaking, result in loss of resolution.
> Instead you get various "contouring" and other artifacts due to the

Exactly that is what i see!

But what to do now? Is there a way to support more ximage input formats?

But, this is going OT now - as it was about Xvideo docs. Still got no 
detailed explanation why i should use the XvPutVideo() function call at all, 
which i thought would solve btw, the problem of the high CPU-load (at least 
reported to me with V3K + NVIDIA + Matrox cards).
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

[Xpert]Re: [Dri-devel] Radeon switch to VT and back X freeze POSSIBLE FIX

[Charl P. Botha]

Dear list,

On Tue, Jul 16, 2002 at 11:02:05PM +0200, Charl P. Botha wrote:
> This is just to add another sample to the Radeon switch to VT and back X
> freeze bug, which is apparently known.

Michel Dänzer and I spent some more time on this bug today.  After having
mucked around with some of the AGP settings (with no success), I did a pre-
and post-crash "lspci -vvv".  The video card was leaving bus mastering mode
when X switched to the console!  It seems this is the root of the VT
switching bug, at least on my system.  At least this specific condition is
easy to test for on the systems of users that experience this crash.

So, appended is a patch that changes the RADEONEnterVT code in
radeon_driver.c so that it re-enables bus mastering mode.  Michel has tested
it on his TiBook (which doesn't have the problem) and the patch doesn't seem
to break anything.

Please apply to the DRI trunk and XFree86 CVS if you think this is
applicable.  If you can keep my name in the source, I'll be even happer.
Yes, small things amuse small minds. ;)

Thanks,
Charl

-- 
charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/


Index: radeon_driver.c
===
RCS file: /cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c,v
retrieving revision 1.22
diff -u -r1.22 radeon_driver.c
--- radeon_driver.c 12 Jun 2002 15:50:28 -  1.22
+++ radeon_driver.c 23 Jul 2002 16:55:16 -
@@ -4435,6 +4435,14 @@
 
 RADEONTRACE(("RADEONEnterVT\n"));
 
+/* This seems to fix that !@#$ irritating switch to VT and back X-freeze
+ * that has been plaguing some DRI users.  It seems that bus mastering
+ * is turned off on the video card when one switches to a VT and this
+ * needs to be reactivated when we get back, else things just stop. :)
+ * Charl P. Botha , 
+ * Michel Daenzer <[EMAIL PROTECTED]> */
+xf86EnablePciBusMaster(info->PciInfo, TRUE);
+
 if (info->FBDev) {
unsigned char *RADEONMMIO = info->MMIO;
 if (!fbdevHWEnterVT(scrnIndex,flags)) return FALSE;

[Xpert]MotionNotify

[jeyasudha]

Hi Xperts,
I want to get all the mouse move events.  I'm using all masks ButtonMotionMask
(for all 5 buttons), PointerMotionMask. Still my window is not getting
the
MotionNotify events whenever i move the mouse. I read PointerMotionHint
Mask
will reduce the motion events to one.  Hence i have not used it.
Which is hogging my MotionNotify events?
Thanks,
JeyaSudha.

**Disclaimer** 
   
 
 Information contained in this E-MAIL being proprietary to Wipro Limited is 
'privileged' 
and 'confidential' and intended for use only by the individual or entity to which it 
is 
addressed. You are notified that any use, copying or dissemination of the information 
contained in the E-MAIL in any manner whatsoever is strictly prohibited.

Re: [Xpert]Accessing selection from command line

[Peter Finderup Lund]

On Wed, 17 Jul 2002, Peter Finderup Lund wrote:

> On Fri, 12 Jul 2002, Ville Herva wrote:
>
> > I was wondering whether people feel that something like this should exist in
> > the XFree86 distribution:
>
> Yes, please!
>
> I was very fortunate to find xcut some months ago, which does the paste
> thing but not the cut:
>
> http://xcut.sourceforge.net/
>
> >   echo puppa | xsel -c  # 'puppa' is now the current X selection
> >   echo puppa | xsel --copy  # same as above
> >
> >   xsel -p | less# pastes the current X selection to less
> >   xsel --paste | less   # same as above
>
> Btw. it should be possible to see if stdin or stdout was a pipe and do the
> right thing automatically.


Here is another similar project:

http://www.goof.com/pcg/marc/xcb.html

-Peter

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: Antwort: Re: Antwort: Re: Antwort: Re: [Xpert]two x-server on one vt

[Dr Andrew C Aitchison]

On Tue, 23 Jul 2002 [EMAIL PROTECTED] wrote:

> But this is not what I want. I want to have two different mice
> on each monitor.

If you have one keyboard, but two mice with different pointers,
how do you you expect the server to know which screen should
receive key presses ?


-- 
Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge
[EMAIL PROTECTED]   http://www.dpmms.cam.ac.uk/~werdna

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: Antwort: Re: Antwort: Re: Antwort: Re: [Xpert]two x-server onone vt

[Peter Finderup Lund]

On Tue, 23 Jul 2002 [EMAIL PROTECTED] wrote:

> Ok, when I use Xinerama, is it not possible to get two separate mice. Then I

Yes it is.

> will get one mouse (one mouse-pointer) which I can move with the two mice.
> Isn't it so?
> But this is not what I want. I want to have two different mice on each monitor.
> Is this possible with Xinerama? If yes, can you tell me please how?

As far as I know you designate one of them to be the "core pointer".
That's the one that will control the mouse pointer.  Programs that need to
(say, CAD programs) can ask to be notified about the other mouse's
position through the X Input Extension.

The two monitors will conceptually be one big screen.   You use the
serverlayout section in the configuration file to tell the server which
one is the left screen and which one is the right one (or top/bottom).
If the resolutions of the two monitors don't quite match, i.e. if the
combined area is not a rectangle, you will get "dead areas" which
conceptually exist but don't have any actual monitor pixels to go with
them.

If the window manager you use is new enough to know about the dead areas
and not put any windows there, this won't be a problem.  Since you are
probably running a newish KDE  I wouldn't worry about it.  Still, should
it turn out to be problematic you can fix it be upgrading.  [just a guess:
since you are both German and running KDE, are you using SuSE?]

The one mouse pointer can be moved from screen to screen with the
"core pointer".

You can use an option in the configuration file called "SendCoreEvents"
which makes the second mouse generate "core events", too, meaning it will
also control the mouse pointer.

Use "man XF86Config" for the details of setting this up.

Here's a tasty quote to whet your appetite:

[...]
Here is an example of a ServerLayout section  for  a  dual
headed configuration with two mice:

Section "ServerLayout"
Identifier  "Layout 1"
Screen  "MGA 1"
Screen  "MGA 2" RightOf "MGA 1"
InputDevice "Keyboard 1" "CoreKeyboard"
InputDevice "Mouse 1""CorePointer"
InputDevice "Mouse 2""SendCoreEvents"
Option  "BlankTime"  "5"
EndSection
[...]

-Peter

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Antwort: Re: Antwort: Re: Antwort: Re: [Xpert]two x-server on one vt

[SST.Lohner]

>> I will see the two X-Servers at the same time and when I tried to display 
them
>> at different vt's I have to change between them with ++(f7/8>. That
>> isn't what I want.
>
>That explains the vt thing.  But why aren't you using Xinerama?  It's much
>better suited to your needs - actually I thought you were going to use
>that as per the earlier discussion on using multiple mice.
>
>http://www.tldp.org/HOWTO/Xinerama-HOWTO.html
>

Ok, when I use Xinerama, is it not possible to get two separate mice. Then I 
will get one mouse (one mouse-pointer) which I can move with the two mice. 
Isn't it so?
But this is not what I want. I want to have two different mice on each monitor. 
Is this possible with Xinerama? If yes, can you tell me please how?

-Thorsten



___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]Trident Cyber9385: display trashed after resume from suspend

[Tino Keitel]

On Thu, Jul 18, 2002 at 10:32:30 +0200, Tino Keitel wrote:
> Hi,
> 
> if I resume from suspend to RAM or suspend to disk while the lid of my
> ThinkPad 765L notebook is closed, the display will be blank, glowing
> slowly to white. I could fix this by switching to a text console,
> activate standby mode (display will be switched off), and resume from
> standby mode. Now the display in the text console is restored and I can
> switch back to X.
> 
> If I use the trident framebuffer for the text console, this trick will
> not work anymore. There seems to be no way to restore the console, or
> am I wrong? Is this a known problem? I have this problem since I
> switched from XFree86 3.3.5 to 4.0.3.
> 
> graphics chip: cyber9385, 2MB
> XFree86 version: 4.2.0
> display: 1024x768 LCD

OK, since nobody else seems to have this problem, can anybody tell me
if the cyber9385 works fine on his machine in the situation mentioned
above and if it's also a TP 765L or another type of notebook?

Thanks in advance.
Tino

-- 
[EMAIL PROTECTED]
dipl.-inf.Innominate Security Technologies AG
software engineer   networking people
tel: +49.30.6392-3308  http://www.innominate.com/
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]nvidia binary driver: kernel BUG at page_alloc.c

[Luca Olivetti]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mike Stilson wrote:


| Just to follow up after giving a little more thought...
| The kernel module doesn't taint it since I'm recompiling it from source.

No, you're just recompiling some glue code, the real module is binary only.

| the NVdriver.o module (although it doesn't specifically have a
| MODULE_LICENSE("GPL")) also doesn't have any conflicting or proprietary
| license.  Now my understanding might be wrong, but it SHOULDN'T be
| tainting the kernel.  Only the X driver (nvidia_drv.o) is closed source.

Yes, it should, in fact I think that kernel developers introduced the
"Tainted" flag specifically for the nvidia module, see this message from
Alan Cox, http://old.lwn.net/2001/0906/a/ac-license.php3, where he states:

"Unfortunately I get so many bug reports caused by the nvidia modules
and people lying when asked if they have them loaded that some kind of
action has to occur, otherwise I'm going to have to stop reading bug
reports from anyone I don't know personally."


Bye
- --
Luca Olivetti
Note.- This message reached you today, it may not tomorrow if you
are using MAPS services. They arbitrarily include in their lists
IP addresses not related in any way to spam, and in so doing are
disrupting Internet connectivity.  Please stop supporting them.
See http://slashdot.org/article.pl?sid=01/05/21/1944247
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: http://www.gnupg.org

iD8DBQE9PWC+CQPXTRx9NmQRAk9YAKCsQ4Vs/WbeYpLIZkifnwgEras7DACgs33R
YImr5J3DGqYfftYR5hPbO8g=
=dE9X
-END PGP SIGNATURE-

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: Antwort: Re: Antwort: Re: [Xpert]two x-server on one vt

[Peter Finderup Lund]

On Tue, 23 Jul 2002 [EMAIL PROTECTED] wrote:

> I will see the two X-Servers at the same time and when I tried to display them
> at different vt's I have to change between them with ++(f7/8>. That
> isn't what I want.

You are using the same keyboard (standard PC compatible) with both
X servers, as far as I can tell from your config files!?!?

How does that work?  Honestly, I can't how it should work at all.  Not
with the X servers being on the same virtual terminal.

I think you should take a look at Xinerama - remember you can use two (or
more) mice if you want to.

-Peter

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: Antwort: Re: Antwort: Re: [Xpert]two x-server on one vt

[Peter Finderup Lund]

On Tue, 23 Jul 2002 [EMAIL PROTECTED] wrote:

> I've two monitors at two Graphic Cards. Now I want to display one X-Server at
> one of them. This is only possible, when I start the X-Servers at ONE vt. One
> time with :0 and one time with :1 and different XF86Configfiles. Isn't it
> correct??

Not really.

> I will see the two X-Servers at the same time and when I tried to display them
> at different vt's I have to change between them with ++(f7/8>. That
> isn't what I want.

That explains the vt thing.  But why aren't you using Xinerama?  It's much
better suited to your needs - actually I thought you were going to use
that as per the earlier discussion on using multiple mice.

http://www.tldp.org/HOWTO/Xinerama-HOWTO.html

> I don't know? Where can I seen this? It's so, that when I press the
> "logout"-Button one display will be black, and the other shows on one half the
> KDE on the other half a very bad text console.

The one with half a KDE image would be my guess ;)

-Peter

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

[Xpert]XSendEvent and Capital/Small Letters.

[Juan José Andrés Gutiérrez]

Hi,

I have a problem with the sending of keys using XSendEvent. When I
send  a letter, for example the letter "a" sends it correctly but when
sends the letter "A" does not send it correctly, but it sends the small
letter (a).

I have made a function that sends a string: SendString(display,
window, string) and I need that the chain sends it correctly.

 Somebody knows since I can do this?


 Thanks.



___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]adding radeon driver documentation

[Michel Dänzer]

On Sun, 2002-07-21 at 10:56, James Ralston wrote: 
> On 17 Jul 2002, Michel Dänzer wrote:
> 
> > On Wed, 2002-07-17 at 08:58, James Ralston wrote:
> > 
> > > (I'd be willing to take a crack at writing a man page for the
> > > radeon driver,
> > 
> > Great! That's very much appreciated.
> 
> Attached is the first draft.
> 
> Besides general proofreading and review, there are 16 FIXMEs in the
> first draft; I would appreciate help in clarifying the points they
> raise.
> 
> > While you're at it, please also add the documentation for options to
> > programs/Xserver/hw/xfree86/Options, which can be used by
> > configuration tools like xf86cfg.
> 
> I'll do that once I have something approaching a final version for the
> radeon(4x) man page (to minimize the number of edits I'll have to do
> in two places).

Good.


Comments (mostly looking at the FIXMEs :):

- reports are probably best directed to this list

- I'd rephrase the description of Option "UseFBDev" along the lines of:

   Option "UseFBDev" "boolean"
  If set to true, XFree86 will attempt to use use an 
OS-specific framebuffer device interface.  See
  fbdevhw(4x) for further information. XFree86 will fail
  to start up if this doesn't work.
  The default is false (meaning, an OS-specific
  framebuffer device interface will not be used,
  the chip will be programmed directly).

Don't miss the 'device' after 'framebuffer'. :)

- the video key is a special color value which is replaced by the video
overlay if and where it's active. It only needs to be changed if the
default value causes undesired effects.

- I think it's correct that the multihead options have no effect with
cards without multiple ports (assuming that all cards with multihead
capable chips have multiple ports)

- I think the comment in RADEONPreInitModes() is accurate, the one in
RADEONGetBIOSParameters() is probably outdated

- the DRI options (except the AGP options) are mostly for debugging and
shouldn't normally be needed. I think describing them might cause more
confusion than it helps. FWIW the r128 manpage doesn't document them.

- yes, Option "AGPMode" does override the AGP mode. I think the
speed-stability tradeoff is well described.

- I don't think Option "AGPSize" is related to the AGP aperture size. It
determines how much of it the driver actually uses, so I'd expect it to
be limited by the aperture size. Again, this shouldn't need to be
changed, certainly not until the driver supports AGP texturing.


Hope this helps, keep up the good work


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]Re: ATI Radeon 8500 support

[Anders Saaby]

Check out 

http://dri.sourceforge.net/snapshots/bleeding-edge/ (r200)

Here you will find the CVS snapshots of Tungsten's Radeon 8500 driver. 

It works (a bit slow though) on my machine.

/Anders

On Thu, 2002-07-18 at 10:37, Ani Joshi wrote:
> 
> Or for 3D 8500 support you could download the FireGL 8xxx driver from
> ATI's website and install that rpm.  I don't know about RedHat 7.3, but it
> works fine on RedHat 7.2.
> 
> 
> ani
> 
> On Thu, 18 Jul 2002, Mike A. Harris wrote:
> 
> > Red Hat Linux 7.3 supports the Radeon 8500, and includes XFree86
> > 4.2.0.  This is 2D only support of course, until 3D support is
> > completed by Tungsten Graphics.
> >
> > The Weather Channel has funded the open source 3D development for
> > the ATI Radeon 8500 (r200 based boards).
> >
> > Hope this helps,
> > TTYL
> >
> > --
> > Mike A. Harris  Shipping/mailing address:
> > OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie,
> > XFree86 maintainer  Ontario, Canada, P6C 5B3
> > Red Hat Inc.
> > http://www.redhat.com   ftp://people.redhat.com/mharris
> >
> > ___
> > Xpert mailing list
> > [EMAIL PROTECTED]
> > http://XFree86.Org/mailman/listinfo/xpert
> >
> 
> ___
> Xpert mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/xpert
-- 


Med venlig hilsen - Best regards 
Anders Saaby
Systems Engineer
__
Cohaesio A/S - Phone:   +45 45 880 888
Maglebjergvej 5D - Fax: +45 45 880 777
DK-2800 Lyngby   - e-mail: [EMAIL PROTECTED]  
__
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: Antwort: Re: Antwort: Re: [Xpert]two x-server on one vt

[John Tapsell]

On Tue, Jul 23, 2002 at 03:01:44PM +0200, [EMAIL PROTECTED] wrote:
> On Tue, 23 Jul 2002 [EMAIL PROTECTED] wrote:
> 
> >> OK, that's fine. I tried this, and it works. Now I have a problem when I want
> >>to logout. If I want to logout, the X-Server is chrashing. So I get no screen
> >> and it hangs up.
> >>
> >> What's about this?
> >
> >Dunno... why do you want them to use the same virtual terminal?
> >
> >
> 
> I've two monitors at two Graphic Cards. Now I want to display one X-Server at 
> one of them. This is only possible, when I start the X-Servers at ONE vt. One 
> time with :0 and one time with :1 and different XF86Configfiles. Isn't it 
> correct??
> I will see the two X-Servers at the same time and when I tried to display them 
> at different vt's I have to change between them with ++(f7/8>. That 
> isn't what I want.

To get two vt's displaying at once you need kernel support.  The
linuxconsole project guys are working on this, and I hear are doing pretty
well so far - check freshmeat or something.

I don't think you can have two x-servers on one VT, but I don't really
know either way :)

> 
> >
> >(which one of the X servers crash on you?)
> >
> 
> I don't know? Where can I seen this? It's so, that when I press the 
> "logout"-Button one display will be black, and the other shows on one half the 
> KDE on the other half a very bad text console.
> 
> -Thorsten
> 
> ___
> Xpert mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/xpert
> 
> 
> ___
> Xpert mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/xpert

-- 



msg07931/pgp0.pgp
Description: PGP signature

Antwort: Re: Antwort: Re: [Xpert]two x-server on one vt

[SST.Lohner]

On Tue, 23 Jul 2002 [EMAIL PROTECTED] wrote:

>> OK, that's fine. I tried this, and it works. Now I have a problem when I want
>>to logout. If I want to logout, the X-Server is chrashing. So I get no screen
>> and it hangs up.
>>
>> What's about this?
>
>Dunno... why do you want them to use the same virtual terminal?
>
>

I've two monitors at two Graphic Cards. Now I want to display one X-Server at 
one of them. This is only possible, when I start the X-Servers at ONE vt. One 
time with :0 and one time with :1 and different XF86Configfiles. Isn't it 
correct??
I will see the two X-Servers at the same time and when I tried to display them 
at different vt's I have to change between them with ++(f7/8>. That 
isn't what I want.

>
>(which one of the X servers crash on you?)
>

I don't know? Where can I seen this? It's so, that when I press the 
"logout"-Button one display will be black, and the other shows on one half the 
KDE on the other half a very bad text console.

-Thorsten

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert


___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: Antwort: Re: [Xpert]two x-server on one vt

[Peter Finderup Lund]

On Tue, 23 Jul 2002 [EMAIL PROTECTED] wrote:

> OK, that's fine. I tried this, and it works. Now I have a problem when I want
> to logout. If I want to logout, the X-Server is chrashing. So I get no screen
> and it hangs up.
>
> What's about this?

Dunno... why do you want them to use the same virtual terminal?
(which one of the X servers crash on you?)

-Peter

"If Bush is serious about his goal of having Palestine democratically
choosing a replacement for Arafat, he's sending the wrong people. He
shouldn't send Colin Powell. The one he should send is Katherine
Harris."
 (seen on advogato.org/person/raph)

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Antwort: Re: [Xpert]two x-server on one vt

[SST.Lohner]

>What if you create a dummy user that belongs to the same group as your
>ordinary user (so they can read/write each other's files) and have
>the dummy user start the second X server?

OK, that's fine. I tried this, and it works. Now I have a problem when I want 
to logout. If I want to logout, the X-Server is chrashing. So I get no screen 
and it hangs up.

What's about this?

-Thorsten


___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert


___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]adding radeon driver documentation

[Dr Andrew C Aitchison]

On Tue, 23 Jul 2002, James Ralston wrote:

> I was tempted to break down support by chipsets instead of cards, but
> I didn't know enough of the mappings among PCI IDs, Radeon chipsets,
> and card names.  (For example, to my knowledge, all "Radeon 8500"
> cards are using the R200 core/chipsets.  What do the QL, QN, QO, Ql,
> and BB revisions mean?  I don't know.)

For those particular letters I don't know, but it isn't hard to pick
two ATI chid IDs for which the the answer would be:
No-one at XFree86 knows the difference between these chips,
but if you have server CVS version XXX one of the chips is
supported and the other isn't. Support for the second chip
is included from CVS version YYY.

I've never been convinced that there was a reliable mapping between
the chip id and the name on the box* so I wouldn't trust a list of 
card names to be accurate enough to say whether the driver will work 
with a particular card.

*I've bought many ATI cards in a white box with no name, or installed
in a new computer with no box at all, where I've had only the sticker
on the card to identify it. The supplier might have sent a revised version
without changing the name on the pricelist, so the card name isn't 
necessarily more help than the chip ID when I try to install linux.

> > It would be worth documenting the work around for unsupported chips:
> > If your card is unsupported, try adding the line
> > ChipId  0xPQRS
> > to the "Devices" section of your config file.
> > 
> > Sorry, I don't know the radeon well enough to suggest the correct
> > value, or values to try in PQRS, we may need to list different
> > values for single and dual head, desktop and laptop, and radeon
> > generations.  Can anyone else help here?
> 
> If I can get some good info on this, I'll be happy to document it,
> but if not, then I'd rather not mention it at all.

I can understand your reluctance, but making people aware that this
can be done is going to help many people to get their card working.
Given that a graphics card becomes obsolete about as fast as a new
version of XFree86 comes out, for anyone who buys a new ATI card,
this trick is about the only alternative to running a CVS version
of the server.

-- 
Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge
[EMAIL PROTECTED]   http://www.dpmms.cam.ac.uk/~werdna

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]two x-server on one vt

[Peter Finderup Lund]

On Tue, 23 Jul 2002 [EMAIL PROTECTED] wrote:

> -  and when i want to start a application at the first x it will work
> correctly. but on the second x the warning "can't do this! please start the
>docpserver!". What's this?

That's a KDE problem (it says "dcopserver", right?).

KDE programs use the X server for interprocess communication, together
with a litle helper application called the DCOPserver.

Maybe KDE doesn't particularly like it if you are using two X servers with
one user.

What if you create a dummy user that belongs to the same group as your
ordinary user (so they can read/write each other's files) and have
the dummy user start the second X server?

Since you are tyring to run two different X servers anyway, I guess you
are not expecting programs on one screen to be able to cooperate with
those on the other so you don't loose anything there.

-Peter

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]nvidia binary driver: kernel BUG at page_alloc.c

[Charl P. Botha]

On Tue, Jul 23, 2002 at 07:16:50AM -0400, Mike Stilson wrote:
> Just to follow up after giving a little more thought...
> The kernel module doesn't taint it since I'm recompiling it from source.
> the NVdriver.o module (although it doesn't specifically have a
> MODULE_LICENSE("GPL")) also doesn't have any conflicting or proprietary
> license.  Now my understanding might be wrong, but it SHOULDN'T be
> tainting the kernel.  Only the X driver (nvidia_drv.o) is closed source.

The kernel module *does* taint it.  You're only building three of the
objects and then linking with "Module-nvkernel", which is binary and which
is where most of the juicy bits are.

-- 
charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]nvidia binary driver: kernel BUG at page_alloc.c

[Mike Stilson]

On Mon, Jul 22, 2002 at 11:25:35PM +0200, Luca Olivetti wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>Mike Stilson wrote:
>Are you sure the nvidia module was loaded at the time of this crash?
>It would taint the kernel if loaded:
>
>Jul  7 20:20:54 pippo kernel: kernel BUG at page_alloc.c:216!
>Jul  7 20:20:54 pippo kernel: invalid operand: 
>Jul  7 20:20:54 pippo kernel: CPU:0
>Jul  7 20:20:54 pippo kernel: EIP:0010:[rmqueue+479/544]Tainted: P
>Jul  7 20:20:54 pippo kernel: EIP:0010:[]Tainted: P

Just to follow up after giving a little more thought...
The kernel module doesn't taint it since I'm recompiling it from source.
the NVdriver.o module (although it doesn't specifically have a
MODULE_LICENSE("GPL")) also doesn't have any conflicting or proprietary
license.  Now my understanding might be wrong, but it SHOULDN'T be
tainting the kernel.  Only the X driver (nvidia_drv.o) is closed source.

Perhaps you have something else tainting it?

-me

-- 
Windows has detected that you have moved your mouse.
Your system must now be restarted for the changes to take effect.
- Unknown
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]Dual-head + dri on an ATI Radeon VE video card

[Michel Dänzer]

On Sun, 2002-07-21 at 07:51, Angus Wallace wrote: 
> 
> I've got a quick question regarding an ATI Raedon VE dual-VGA-out card.
> I've read in several places that the driver doesn't currently support
> both dri and dual-head at the same time. Is this still the case?

Yes.

> Is it likely to be addressed in the future, and if so when?

The best solution would probably be to implement what nVidia calls
'TwinView' and Matrox calls 'merged display' I think. There were plans
to do so but I don't know about the current status.

Meanwhile, if you don't need DRI on both heads, run one server
dualheaded with no DRI and another singleheaded with DRI. Very easy with
gdm. 


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Re: [Xpert]Opengl program performance drops after upgrading toXFree86 4.2

[Michel Dänzer]

On Tue, 2002-07-23 at 05:43, Jason Hu Huang wrote:
> 
> I have just upgraded my RH7.2 box's x server from 4.1 to 4.2. I found the 
> performance of the opengl program that I am working on drops significantly.
> The original framerate is 40 fps, and now it is only around 20 fps. Can anyone 
> tell me why this happens, and how I can solve it.

Is direct rendering enabled with 4.2? Check the server log and/or
glxinfo output.


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

[Xpert]two x-server on one vt

[SST.Lohner]

i want to start two x-server on one vt but on two different monitors. i get 
this correctly by using

startx -- :0 -xf86config XF86Config0 vt07
startx -- :1 -xf86config XF86Config1 vt07

so i can see two displays with different mouse pointer and one keyboard. and 
there are the problems:

-  the two mouse pointers are working correct

-  but the keyboard not. when i will type something on the first x sometimes it 
will do this and sometimes it write it on the second x. so it is not 
   correctly configured?

-  and when i want to start a application at the first x it will work 
correctly. but on the second x the warning "can't do this! please start the 
   docpserver!". What's this?

who can help me?


XF86Config0:

# /.../
# SaX generated XFree86 config file
# Created on: 1998-01-22.
#
# Version: 4.3
# Contact: Marcus Schaefer <[EMAIL PROTECTED]>, 2001
#
# Automatically generated by [SaX2] (4.3)
# PLEASE DO NOT EDIT THIS FILE!
#
Section "Files"
  FontPath "/usr/X11R6/lib/X11/fonts/misc:unscaled"
  FontPath "/usr/X11R6/lib/X11/fonts/local"
  FontPath "/usr/X11R6/lib/X11/fonts/75dpi:unscaled"
  FontPath "/usr/X11R6/lib/X11/fonts/100dpi:unscaled"
  FontPath "/usr/X11R6/lib/X11/fonts/Type1"
  FontPath "/usr/X11R6/lib/X11/fonts/URW"
  FontPath "/usr/X11R6/lib/X11/fonts/Speedo"
  FontPath "/usr/X11R6/lib/X11/fonts/PEX"
  FontPath "/usr/X11R6/lib/X11/fonts/cyrillic"
  FontPath "/usr/X11R6/lib/X11/fonts/latin2/misc:unscaled"
  FontPath "/usr/X11R6/lib/X11/fonts/latin2/75dpi:unscaled"
  FontPath "/usr/X11R6/lib/X11/fonts/latin2/100dpi:unscaled"
  FontPath "/usr/X11R6/lib/X11/fonts/latin2/Type1"
  FontPath "/usr/X11R6/lib/X11/fonts/latin7/75dpi:unscaled"
  FontPath "/usr/X11R6/lib/X11/fonts/baekmuk:unscaled"
  FontPath "/usr/X11R6/lib/X11/fonts/japanese:unscaled"
  FontPath "/usr/X11R6/lib/X11/fonts/kwintv"
  FontPath "/usr/X11R6/lib/X11/fonts/truetype"
  FontPath "/usr/X11R6/lib/X11/fonts/uni"
  FontPath "/usr/X11R6/lib/X11/fonts/CID"
  FontPath "/usr/X11R6/lib/X11/fonts/ucs/misc"
  FontPath "/usr/X11R6/lib/X11/fonts/ucs/75dpi:unscaled" 
  FontPath "/usr/X11R6/lib/X11/fonts/ucs/100dpi:unscaled"
  FontPath "/usr/X11R6/lib/X11/fonts/hellas/misc:unscaled"
  FontPath "/usr/X11R6/lib/X11/fonts/hellas/75dpi:unscaled"
  FontPath "/usr/X11R6/lib/X11/fonts/hellas/100dpi:unscaled"
  FontPath "/usr/X11R6/lib/X11/fonts/hellas/Type1"
  FontPath "/usr/X11R6/lib/X11/fonts/misc/sgi"
  FontPath "/usr/X11R6/lib/X11/fonts/xtest"
  ModulePath   "/usr/X11R6/lib/modules"
  RgbPath  "/usr/X11R6/lib/X11/rgb"
EndSection

Section "ServerFlags"
  Option   "AllowMouseOpenFail"
EndSection

Section "Module"
  Load "type1" 
  Load "speedo" 
  Load "extmod"
  Load "freetype"
EndSection

Section "InputDevice"
  Driver   "Keyboard"
  Identifier   "Keyboard[0]"
  Option   "Protocol" "Standard"
  Option   "XkbLayout" "de" 
  Option   "XkbModel" "pc104"
  Option   "XkbRules" "xfree86"
  Option   "XkbVariant" "nodeadkeys"
EndSection

Section "InputDevice" 
  Driver   "mouse" 
  Identifier   "Touch"
  Option   "Device" "/dev/ttyS0" 
  Option   "Name" "Autodetection"
  Option   "Protocol" "IntelliMouse"
  Option   "Vendor" "Sysp"
EndSection

Section "Monitor"
  HorizSync27-65
  Identifier   "Testdsp"
  ModelName"640X480@70HZ"
  VendorName   "--> LCD"
  VertRefresh  55-60
  UseModes "Modes[0]"
EndSection

Section "Modes"
  Identifier   "Modes[0]"
  Modeline  "640x480" 23.96 640 656 720 864 480 480 484 501
EndSection

Section "Screen" 
  DefaultDepth 16
   SubSection "Display"
Depth  15
Modes  "640x480"
  EndSubSection
  SubSection "Display"
Depth  16
Modes  "640x480" 
  EndSubSection
  SubSection "Display"
Depth  24
Modes  "640x480"
  EndSubSection
  SubSection "Display"
Depth  32
Modes  "640x480"
  EndSubSection
  SubSection "Display"
Depth  8
Modes  "640x480" 
  EndSubSection
  Device   "Device[0]"
  Identifier   "Screen[0]"
  Monitor  "Testdsp"
EndSection

Section "Device"
  BoardName"Voodoo 3"
  BusID"2:11:0"
  Driver   "tdfx"
  Identifier   "Device[0]"
  VendorName   "3Dfx"
EndSection

Section "ServerLayout"
  Identifier   "Layout[0]"
  InputDevice  "Keyboard[0]" "CoreKeyboard"
  InputDevice  "Touch" "CorePointer"
  Option   "Clone" "off"
  Option   "Xinerama" "off"
Screen   "Screen[0]"
EndSection

Section "DRI"
  Group  "video"
  Mode   0660
EndSection


XF86Config1:

# /.../
# SaX generated XFree86 config file
# Created on: 1998-01-22.
#
# Version: 4.3
# Contact: Marcus Schaefer <[EMAIL PROTECTED]>, 2001
#
# Automatically generated by [SaX2] (4.3)
# PLEASE DO NOT EDIT THIS FILE!
#
Section "Files"
  FontPath "/usr/X11R6/lib/X11/fonts/misc:unscaled"
  FontPath "/usr/X11R6/lib/X11/fonts/local"
  FontPath

Re: [Xpert]adding radeon driver documentation

[James Ralston]

On Sun, 21 Jul 2002, Dr Andrew C Aitchison wrote:

> While the most asked question is "Does the driver support my card ?"
> I'm uncomfortable about the man page listing the supported cards,
> for several reasons:
> 
> 1) For the most part the driver supports chips, not cards.  ATI have
> a strong habit of releasing chips with new IDs without necessarily
> changing the name on the box or card.

I'd be happy to replace that section with a pointer to a more
up-to-date list of supported Radeon cards, but I know of no such
source of information.  (Even the driver status notes for 4.2.0 just
say "Radeon chips".)

I was tempted to break down support by chipsets instead of cards, but
I didn't know enough of the mappings among PCI IDs, Radeon chipsets,
and card names.  (For example, to my knowledge, all "Radeon 8500"
cards are using the R200 core/chipsets.  What do the QL, QN, QO, Ql,
and BB revisions mean?  I don't know.)

> It would be worth documenting the work around for unsupported chips:
> If your card is unsupported, try adding the line
> ChipId  0xPQRS
> to the "Devices" section of your config file.
> 
> Sorry, I don't know the radeon well enough to suggest the correct
> value, or values to try in PQRS, we may need to list different
> values for single and dual head, desktop and laptop, and radeon
> generations.  Can anyone else help here?

If I can get some good info on this, I'll be happy to document it,
but if not, then I'd rather not mention it at all.

> 2) Man pages are not as frequently maintained as drivers. You should
> (must) put a prominent line in the list, saying something like: The
> list of cards known to work changes frequently (monthly?)  As of 21
> July 2002 the following cards are known to work:

Will do.

> Dac6Bit:
> SWcursor:

Thanks for the info; I've updated the man page.  (I haven't included
an updated version, because very little changed.)

Again, I solicit feedback from the entire list.  14 FIXMEs remain, and
I know that for each remaining FIXME, there are people reading this
list who can easily complete/reconcile the information...

-- 
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA

___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert