Re: does XFree86 need kernel framebuffer support?
Dear Sir, Thanks for your valuable information. --- Andrew C Aitchison <[EMAIL PROTECTED]> wrote: > XFree86 does not in general need kernel framebuffer > support for > hardware which is supported by an XFree86 driver, as > it has its own > framebuffer interface. This almost solves our problem because our kernel have no support for DRI or framebuffer. > > There are two cases where XFree86 does need kernel > support. > * Chipsets like the i810/i815/i835/... family have > no framebuffer memory > but use main system memory for the framebuffer. This > requires agpgart > support from the kernel. does agpgard is specificaly for AGP? or can we use it for PCI? I need to check whether our integrated PCI-ATI Rage is having its own memory or sharing system memory. > The XFree86 mach64 driver does not use kernel > support, > There is an XFree86 driver (fbdev IIRC) which uses > kernel framebuffer > support, and some XFree86 drivers can work with a > kernel framebuffer We are going to use Mach64 server and as of now we are not interested in DRI. Once we successfuly port Xfree86 to our new platform with basic server then we can concentrate on other server implementations. Thanks & Regards, Suresh. = --- Suresh Chandra Mannava. Research Scholar, V I T, India. Abacus, X & GNOME porting Cornet Tech India mannavavit.ac.in Yahoo! India Mobile: Download the latest polyphonic ringtones. Go to http://in.mobile.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
bsd_mouse.c - small patch
Don't place tokens after #endif preprocessor directive. Index: bsd_mouse.c === RCS file: /cvs/xc/programs/Xserver/hw/xfree86/os-support/bsd/bsd_mouse.c,v retrieving revision 1.27 diff -u -p -r1.27 bsd_mouse.c --- bsd_mouse.c 17 Jan 2004 15:20:05 - 1.27 +++ bsd_mouse.c 6 Feb 2004 06:55:48 - @@ -378,7 +378,7 @@ FindDevice(InputInfoPtr pInfo, const cha } return *pdev; } -#endif (__OpenBSD__) +#endif /* (__OpenBSD__) */ #ifdef WSCONS_SUPPORT #define NUMEVENTS 64 Thanks -- Tyler R. Retzlaff <[EMAIL PROTECTED]> http://www.NetBSD.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Virtual Xinerama
Hello, I recently aquired a second video card, so that I now have a triple display. I'm using a Nvidia card (with the binary drivers) in TwinView Mode to drive the first two displays and a Ati card for the third display. What really annoys me is, that as as soon as you enable TwinView together with a second card, the two displays are just seen as one screen and so every window manager only 'sees' two screens. So maximized windows etc. always strech over (at least) two displays. As I don't think Nvidia will be fixing this anytime soon and I think this could probably useful elsewhere (i.e. dividing your display into two screens so that window always are maximized to half the window, ...), I'm wanting to implement a kind of virtual xinerama support. I've thought about different ways of implementing this. The easiest solution I can see so far is to just extend the screen definitions in my ServerLayout like the following example: Section "ServerLayout" ... Screen 0 "NvScreen" Geometry 1280 1024 0 0 Screen 1 "NvScreen" Geometry 1280 1024 1280 0 RightOf "0" Screen 2 "AtiScreen0" RightOf "1" Of course RightOf, LeftOf, etc. would have to be made to work with screen-nums and screen-ids. Also checks for non overlapping of areas would have to be done. And only dividing of hole screens will be supported, no funny part of this and part of that screen. So, what do you think of the general idea? Is this just totally bogus or may this be useful? Especially, are their other ways (other than hacking every wm out there) to do this better/cleaner/faster? Thanks for any comments, suggestions and hints, Jan ps: I already started hacking on this. Seems like I've to dig quite deep into the xinerama layer. :-) pgp0.pgp Description: PGP signature
Re: Virtual Xinerama
Jan Dittmer wrote:
ps: I already started hacking on this. Seems like I've to dig quite deep
into the xinerama layer. :-)
Okay, after looking into this, I think what I really just want to do is
to fake the reply of PanoramiX{GetScreenCount,GetScreenSize,},
XineramaQueryScreens. Emulatins multiple screens, like first thought,
gets far too complex. Are there any other places window managers get
there screen information from in xinerama mode other than those 3?
Thanks,
Jan
pgp0.pgp
Description: PGP signature
Re: hi
- The following is an automated response - to your message generated on behalf of [EMAIL PROTECTED] Dear O2 Customer, Please note that this is an unmonitored email account and we will not be able to respond to your query. If you have a query about your service please visit www.o2.co.uk/help or email us at mailto:[EMAIL PROTECTED] where it will receive our attention. Regards, O2 Customer Care This communication is from O2 (Online) Limited. Registered office: Wellington Street, Slough, Berkshire, SL1 1YP. Registered number: 1906156. Business office: The Broadway, Hammersmith, London W6 9DL. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Manufacturers who fully disclosed specifications for agp cards?
- Original Message - From: "netpython" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, February 04, 2004 9:38 AM Subject: *** GMX Spamverdacht *** Re: *** GMX Spamverdacht *** Re: Manufacturers who fully disclosed specifications for agp cards? [...] > (reverse engineering) > Are there any good tools to do that under linux ? there are a few dis-assemblers and debuggers around for Linux, but the most promising approach to my understanding is the emulation approach. there are projects which do make run e.g. windows printer drivers on Linux via emulation (e.g. Wine), other driver models will follow that soon and then you should have full abilities on intercepting nearly anything what goes on. lets consider even the newly announced coLinux (@sf.net) approach as some basic approach for an emulation platform. -Alex. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Virtual Xinerama
--- Jan Dittmer <[EMAIL PROTECTED]> wrote: > Hello, > > I recently aquired a second video card, so that I now have a triple > display. I'm using a Nvidia card (with the binary drivers) in > TwinView > Mode to drive the first two displays and a Ati card for the third > display. What really annoys me is, that as as soon as you enable > TwinView together with a second card, the two displays are just seen > as > one screen and so every window manager only 'sees' two screens. So > maximized windows etc. always strech over (at least) two displays. > As I don't think Nvidia will be fixing this anytime soon and I think > this could probably useful elsewhere (i.e. dividing your display into > > two screens so that window always are maximized to half the window, > ...), I'm wanting to implement a kind of virtual xinerama support. > I've thought about different ways of implementing this. The easiest > solution I can see so far is to just extend the screen definitions in > my > ServerLayout like the following example: > > Section "ServerLayout" > ... > Screen 0 "NvScreen" Geometry 1280 1024 0 0 > Screen 1 "NvScreen" Geometry 1280 1024 1280 0 RightOf "0" > Screen 2 "AtiScreen0" RightOf "1" > > Of course RightOf, LeftOf, etc. would have to be made to work with > screen-nums and screen-ids. Also checks for non overlapping of areas > would have to be done. And only dividing of hole screens will be > supported, no funny part of this and part of that screen. > So, what do you think of the general idea? Is this just totally bogus > or > may this be useful? Especially, are their other ways (other than > hacking > every wm out there) to do this better/cleaner/faster? > > Thanks for any comments, suggestions and hints, Drivers that implement their own xinerama extension are not compatible with the "official" xinerama extension (It's not that they are incompatiable, rather you can only have one xinerama extension registered at a time). right now you can only have one or the other. Torrey Lyons mentioned extending the xinerama extension at one point to better accomodate things like merged framebuffer modes and other windowing systems that provide their own multi-mon API such as Apple. I don't know that anyone has really done anything on this at the moment though. Take a look at the sis driver or the radeon driver in DRI cvs or the pseudo-xinerama stuff in the quartz code for an idea of how this should work for driver based xinerama extensions. Ideally the official extension would be extended to handle both cases. If you come up with a patch, please post! Alex > > Jan > > ps: I already started hacking on this. Seems like I've to dig quite > deep > into the xinerama layer. :-) > > ATTACHMENT part 2 application/pgp-signature __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: does XFree86 need kernel framebuffer support?
On Fri, 6 Feb 2004, [iso-8859-1] Suresh Chandra Mannava wrote: > > There are two cases where XFree86 does need kernel > > support. > > * Chipsets like the i810/i815/i835/... family have > > no framebuffer memory > > but use main system memory for the framebuffer. This > > requires agpgart > > support from the kernel. > > does agpgard is specificaly for AGP? or can we use it > for PCI? I've never used it, but I've seen references to pcigart, which provides (some of) the features of the agpgart kernel module for PCI devices. After a quite google, I'm not sure whether it is actually a kernel module, or part of the Mach64 DRI project: http://www.ussg.iu.edu/hypermail/linux/kernel/0102.1/0959.html suggests that it may come with the DRI, but http://mail-index.netbsd.org/tech-x11/2003/03/19/0006.html suggests that it may come with the OS kernel. (The first is quite old, but sugegsts that at the time pcigart may not have had support for the Mach64). My Mach64 is about 5 years old, and I've never needed a kernel module for it, but I know that some of the later, more integrated, versions were somewhat different. As Tim Roberts says, even with system memory, you may not need the gart functions, if the BIOS allocates enough memory to the graphics unit. Since you are on a custom platform that may or may not help you. -- Andrew C. Aitchison Cambridge [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: bsd_mouse.c - small patch
On Fri, 6 Feb 2004, Tyler Retzlaff wrote: > Don't place tokens after #endif preprocessor directive. > Index: bsd_mouse.c > === > RCS file: > /cvs/xc/programs/Xserver/hw/xfree86/os-support/bsd/bsd_mouse.c,v > retrieving revision 1.27 > diff -u -p -r1.27 bsd_mouse.c > --- bsd_mouse.c 17 Jan 2004 15:20:05 - 1.27 > +++ bsd_mouse.c 6 Feb 2004 06:55:48 - > @@ -378,7 +378,7 @@ FindDevice(InputInfoPtr pInfo, const cha > } > return *pdev; > } > -#endif (__OpenBSD__) > +#endif /* (__OpenBSD__) */ > > #ifdef WSCONS_SUPPORT > #define NUMEVENTS 64 > Thanks Done. Thanks for the patch. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: does XFree86 need kernel framebuffer support?
Sergey Babkin wrote: Tim Roberts wrote: Andrew C Aitchison wrote: There are two cases where XFree86 does need kernel support. * Chipsets like the i810/i815/i835/... family have no framebuffer memory but use main system memory for the framebuffer. This requires agpgart support from the kernel. This doesn't actually REQUIRE agpgart support from the kernel unless you're doing bus mastering. The ProSavages are UMA chips, with their frame buffers in main memory, and as long as the BIOS has done the proper division of memory at boot time, that's all it needs. Many of the cards in the i810 family have only a very limited amount of video memory on the card. So if you want to get anything over 800x600 on them, you need agpgart. On some of them the i810 driver won't start even in 800x600 mode, so VESA is the only option. I was about to express my utter confusion at these comments, since in fact the i810 family (just like the ProSavages and other UMA solutions) has exactly zero megabytes on-chip video memory, but after doing some reading, I think I understand now. The issue here, if I understand it, is that the BIOS on i810 systems is utterly brain-dead. It will not allocate more than 1 MB of system RAM to the i810. Thus, if you want more than 1024x768x8 or 800x600x16, you do, in fact, need agpgart support to remap the addresses. This is NOT the case for ProSavage chips, nor for any of the other UMA chips I've encountered (like SiS). In those cases, the BIOS carves up the system memory, and is able to allocate 8MB or 16MB or more to the graphics chip. In that case, agpgart is not necessary. So, I guess I learned something today. -- - Tim Roberts, [EMAIL PROTECTED] Providenza & Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
I830M Second display enabling (Intel datasheet)
Not sure if this helps at all, but there is mentioned something about the enabling of the secondary video device on I830M chipset. The datasheet is available at following address: ftp://download.intel.com/design/chipsets/datashts/29833803.pdf On the page 81, this is said about the GCC1-GMCH Control Register #1 Device #0: Address Offset 52-53h, bit 3: Device #2 Disable - When set to "1" this bit disables Device #2 and all associated spaces (Default value = 0) bit 2: Device #2 Function 1 Enable - When set to "1", enables the second function within Device #2 (Default Value = 0). It is said that these "I/O mapped registers reside in the CPU I/O addres space - the configuration address (CONFIG_ADDRESS) and the configuration data (CONFIG_DATA) register. The configuration address register enables/disables the configuration space and determines what portion of configuration space is visible through the configuration data window." There's also information about the CONFIG_ADDRESS and usage of it, starting at page 65. But I guess there's no reason for me to copy it all here, as it is available in the mentioned url... :-) Well, I haven't ever programmed any hardware-related stuff, and all I can do is hope this information might be for some use.. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Multiple sessions accessed simultaneously
Hello, I was just trying to get a feel for what people are looking at doing (ie plans etc..) in regards to having a X session running on more than one VT, on seperate monitors, that can be accessed by two different people simultaneously. This would ovbiously require multiple input devices, two mice and keyboards. Problem as I see it from the vanilla source tree is that no two VT's can be active simultaneously, and that device binding/exclusion for input on that VT is not supported. After all it would be a tad hard to work on a system when somewhen else move another mouse and your cursor moved with it :) Thanks Andrew Bevitt ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: does XFree86 need kernel framebuffer support?
On Fri, 2004-02-06 at 10:30, Andrew C Aitchison wrote: > On Fri, 6 Feb 2004, [iso-8859-1] Suresh Chandra Mannava wrote: > > > does agpgard is specificaly for AGP? Yes. > > or can we use it for PCI? > > I've never used it, but I've seen references to pcigart, > which provides (some of) the features of the agpgart kernel > module for PCI devices. > After a quite google, I'm not sure whether it is actually a kernel > module, or part of the Mach64 DRI project: > http://www.ussg.iu.edu/hypermail/linux/kernel/0102.1/0959.html > suggests that it may come with the DRI, but > http://mail-index.netbsd.org/tech-x11/2003/03/19/0006.html > suggests that it may come with the OS kernel. > (The first is quite old, but sugegsts that at the time pcigart > may not have had support for the Mach64). As the first post says, PCI GART is a feature of ATI graphics chips; AFAIK it's only provided by Rage128 and later. -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
XGetImage and Pixmap/Xvfb
I'm having problems grabbing images from XPixmap objects, whether
created on a visible Display or on a Xvfb display. Specifically, I'm
drawing a fill which is stippled. If the Drawable is a visible window,
XGetImage works fine. When the Drawable is XPixmap, the filled area is
solid.
I tried to boil this down to some simple X test program, and I can't
even get that to capture an image from the pixmap on the normal display,
I get BadWindow errors. I can however, use identical code and capture
from a visible window, and things work fine.
man pages and Xlib Programming Manual offer no help (that I can find).
I've tried this on my laptop (16bit depth) and my desktop (24bit). Both
give the same errors. Can anyone provide some clues?
g++ -o test test.cxx -L/usr/X11R6/lib -lXm -lXt -lx
./test
Creating visible window
Realizing widget
Creating Window
Creating DrawingArea
Getting Display
Allocating GC2
DefaultDepth: 16
Clearing Window1
Getting pixels
Allocating GC
Set foreground
Clearing Window
Allocating fill pixmap2
Setting fill pixmap
Drawing rectangle
Flushing
Done drawing
Capturing image 3c00014
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 61 (X_ClearArea)
Resource id in failed request: 0x3c00014
Serial number of failed request: 154
Current serial number in output stream: 164
#define's at top choose whether XImage is captured from Pixmap or
visible window.
Hope this is clear...
#define VIS 1
#define PIXMAP 1
#include
#include
#include
#include
#include
#include
#if VIS
#include
#include
#endif
GC CreateGC(Display* dsp, Window win)
{
int screen = DefaultScreen(dsp);
XGCValues values;
values.function = GXcopy;
values.plane_mask = AllPlanes;
values.line_width = 0;
values.line_style = LineSolid;
values.cap_style= CapButt;
values.fill_style = FillSolid;
values.join_style = JoinBevel;
values.subwindow_mode = ClipByChildren;
values.graphics_exposures = False;
values.clip_x_origin= 0;
values.clip_y_origin= 0;
values.clip_mask= None;
values.foreground = WhitePixel(dsp, screen);
values.background = BlackPixel(dsp, screen);
values.join_style = JoinRound;
GC gc = XCreateGC(dsp, win,
GCFunction|GCPlaneMask|GCLineWidth|
GCLineStyle|GCCapStyle|
GCFillStyle|GCJoinStyle|GCForeground|
GCBackground|GCSubwindowMode|
GCGraphicsExposures|GCClipXOrigin|
GCClipYOrigin|GCClipMask,
&values);
if (gc == None) {
printf("Unable to get GC\n");
exit(-1);
}
return gc;
}
void SetFillStipple(Display* dsp, Window win, GC gc)
{
unsigned char opaque_bits[] = {
0x55, 0x50, 0xa0, 0xaa, 0x50, 0x55, 0xaa, 0xa0, 0x55, 0x50, 0xaa, 0xa0,
0x55, 0x50, 0xa0, 0xaa, 0x50, 0x55, 0xaa, 0xa0, 0x55, 0x50, 0xaa, 0xa0,
0x55, 0x50, 0xa0, 0xaa, 0x50, 0x55, 0xaa, 0xaa};
Pixmap fillPix = XCreatePixmapFromBitmapData(dsp, win,
(char *)opaque_bits,
16, 16,
1, 0, 1);
printf("Setting fill pixmap\n");
XSetFillStyle(dsp, gc, FillStippled);
XSetStipple(dsp, gc, fillPix);
XFreePixmap(dsp, fillPix);
}
XImage* Capture(Display* dsp, Window win)
{
XImage* ximage = XGetImage(dsp, win,
0, 0, 800, 800,
(unsigned long)0x00ff, ZPixmap);
if(ximage)
printf("Captured image\n");
else{
printf("Unable to grab image\n");
exit(-1);
}
return ximage;
}
void DrawRectangle(Display* dsp, Window win, GC gc)
{
printf("Set foreground\n");
XSetForeground(dsp, gc, 0x00ff00);
XSetBackground(dsp, gc, 0xff);
printf("Clearing Window\n");
XClearWindow(dsp, win);
printf("Allocating fill pixmap2\n");
SetFillStipple(dsp, win, gc);
printf("Drawing rectangle\n");
XFillRectangle(dsp, win, gc, 350, 350, 100, 100);
printf("Flushing\n");
XFlush(dsp);
printf("Done drawing\n");
}
int main(int argc, char** argv)
{
const char* displayName = ":0.0";
#if VIS
printf("Creating visible window\n");
XtAppContext context;
Widget Gwindow, Ggraf;
Widget topLevel = XtVaAppInitialize(&context,
"PG",
NULL,0,
&argc,argv,
NULL,
XmNwidth,800,
XmNheight,800,
XVideo seems to work on NeoMagic NM2097
Hello, I have a Mitsubishi AMiTY CN2 notebook with a NeoMagic NM2097 (MagicGraph 128ZV+) video chipset. I was excited to see that XVideo support was added for NeoMagic chipsets in XFree86 version 4.3, but for the life of me, I could not get it to work. (I did add the OverlayMem option to my XF86Config.) xvinfo just gave me the dreaded "No adapers present." I'm not much of a programmer, but I looked through the neomagic driver source code, and apparently the driver only activates a video overlay for chipsets NM2160 (MagicGraph 128XD) and newer. So just for the heck of it, I added the following line to my XF86Config: Chipset "neo2160" I started up X, ran xvinfo... and I got a nice list of all the video modes supported by the NeoMagic Video Engine! Wow! Could it be that simple? I played an MPEG video in full-screen mode with XINE, and sure enough, video performance was significantly improved compared to the XShm output device. I even moved another window on top of the video, and I could see parts of the video showing through the colors that matched the chromakey. The only problem I had was the cursor turned into a scattered mess of dots instead of a nice arrow. I noticed in XFree86.0.log that the neomagic driver detected 2 MB of video memory when in fact I only have 1152 kB. So I added one more line to my XF86Config: VideoRam 1152 And that fixed the cursor. All other functions seem to work fine. I am running 800x600 @ 16 bpp. The other warning I received in the log file was: "Can not reserve 829440 bytes for overlay. Resize to 218624 bytes." But I'm still able to play full-screen videos. Is there any reason the neomagic driver shouldn't activate the video overlay on a NM2097 chipset? (Maybe it would work on even older chipsets?) It would sure be a nice feature addition for the upcoming version 4.4... Thanks for your support, Karl O. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
