Re: [Xpert]USB Keypad
On July 18, 2002 08:09 pm, Josh Litherland wrote about "[Xpert]USB Keypad": > I want to simultaneously use a PS/2 keyboard (This is a laptop, so > switching that out is not an option) and a USB numeric keypad, which > works perfectly as a usb HID keyboard. Is there any way to do this > with the current keyboard driver ? (I'm assuming your using some flavour of Linux 2.4.x such as RedHat 7.x, Mandrake 8.x etc) Just plug it in and it should work. I have a PS/2 keyboard and a USB Keyboard plugged in at the same time right now and they both work fine. Most recent distros it should be as simple as that. If that doesn't work, make sure these kernel modules are loaded: keybdev hid input usb-ohci or usb-uhci, depending on your usb controller usbcore ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Regoin Screen n Framebufer
Mark Vojkovich wrote: >On Thu, 18 Jul 2002, Preetham wrote: > >>Thanx Mark, >>Before i get to clarifying what my last question in the prev mail was >>about, i have another >>doubt. >>I was reading thru the server architecture document and came accross the >>Shadow FB Engine. >>"The Shadow FB engines use Keith Packard's FB drawing procedures wrapped >>with his Shadow layer that allows drawing to an offscreen framebuffer >>with periodic updates of the primary framebuffer." >>What i understood by this is, i can create a copy of the framebuffer in >>the memory(possibly save it to the hard drive) and use it like a windows >>bitmap. This bitmap will have the image of the screen(Eg: a linux >>desktop equivalent to a windows desktop snapshot). >> > > The shadowfb wraps rendering functions and tells you which parts >of the framebuffer has been updated. The common usage is to put >the framebuffer (what all the rendering code thinks is the framebuffer) >in system memory so that all rendering goes into that. Shadowfb's >callbacks telling you which parts have been modified would allow you >to copy those parts from the system memory buffer to another buffer >(such as a video ram buffer) keeping those two buffers in sync. >However, since the X-server is now rendering in system memory you >have eliminated the possibilty of hardware acceleration. > > You could do just the opposite though, and have shadowfb wrap >rendering into the video ram framebuffer and you could get informed >of modified areas. A layer that did this could probably be >installed as an extension module and work with all drivers without >any modifications to the core X-server binary. > What was the purpose of getting the system memory in between the video ram memory, since it is obvious that it would be slower than doing it the other way around. When is the framebuffer updated by the XServer, is it based on some timer, or is it based on events, or is it triggered by the X Client. > >>What i meant by my last question was: If my preveious inference is >>correct, then can i use this >>Shadow Engine, or write an engine of my own that would capture the >>graphic information of only the active window(top level window) of the >>screen. >>What i am looking to do is, open an appication and only capture the >>graphics related to the >>window the application opens. >> > > You could modify shadowfb to inform you only about updates to particular >windows, yes. Well, a corner case is when somebody draws on a parent >of that window with IncludeInferiors, for example when the window manager >draws XOR'd lines on the root window when placing windows. If you just >trapped for actions on your window you wouldn't see that, but it may >be that you're not interested in capturing that. Other corner cases >are that you won't know about OpenGL rendering because it would be >direct rendered by the client without X-server involvement. > > What is the intended purpose? Are you trying to monitor particular >windows remotely? Was the idea to have the X-server notify when there >was new data and provide minimum updates or something? > > > Mark. > What i am looking to do: I have my client MyClient running in my machine, that connects to MyServer running in a remote Linux box. I am looking to run the Xserver along with the X client in the same Linux box. I connect to the Linux box, start a new session, open an application, capture the graphic display of the application(all done by MyServer using the Xserver) and send it back to MyClient. Also, instead of opening a new application, i would want to hook onto an existing application opened in one of the display numbers e.g. server:2, to view only its graphical display on MyClient. I am looking to write something like the Xserver, or modify the current XServer to do the job for me. This is a very basic requirment which i would like to extend later. Thanks, Preetham. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]pan locking / sroll locking the viewport in X
> On Thu, 18 Jul 2002 [EMAIL PROTECTED] wrote: > > > > On Wed, 17 Jul 2002, Christopher A Len wrote: > > > > > > > Is there a way to lock the viewport from panning to other areas of the > > > > virtual desktop? Normally, I run 1152x864 desktop and 1152x864 viewport. > > > > However, I want to be able to zoom in on a window (eg change viewport to > > > > 640x480 or 800x600), and keep the viewport from scrolling when the pointer > > > > hits the screen edge. Is there a way to do this? I tried scroll lock, it > > > > had no effect. My keyboard map is us104. Any feedback would be > > > > appreciated. I cant imagine something like this hasn't been implemented > > > > yet... > > > > > > > > > >We've discussed this years ago. It's possibly not difficult to > > > implement either. Nobody seemed to care enough about it to do this > > > though. Somebody would have to care enough about it to volunteer > > > to do the work. You perhaps? > > > > I actually had this working in my tree at home a couple of years ago. > > That is, I could move the viewport, press ScrollLock, and then the viewport > > was locked in that position until ScrollLock was pressed again. There > > were some complications though: > > > > 1) There needed to be a way to configure which key controlled the viewport lock > > > > 2) A client-side interface would have been useful. For example, a window manager > > could receive an event when the viewport was locked and remap the positions of > > windows to fit within the visable viewport. Or it could have initiated the > > viewport lock. Maybe allowing a client to enable/disable the effect of the > > ScrollLock key would have been nice. > > > > 3) How do you mix it with Xinerama or even plain multi-head configs? Should > > moving the mouse to the edge of the viewport trigger a switch to another screen? > > > >It's not clear what the best behavior is. Also, when one modeswitches, > that modeswitch goes into effect on the head the pointer is on at that > time. The Scroll-lock key, however, would imply a global action, not > a head-specific action. Maybe another hotkey would be better than the > scroll-lock key. Ah, yes, I thought of that at the time, but had forgotten about that problem. It could be resolved by a good implementation of a client lib (item #2 above) together with a client that allowed you to configure what triggered a viewport lock on each screen. Alternatively, I suppose you could just (un-)lock whichever screen had the pointer at the time, but this kind of thing leads to parts of the server needing access to data structures that aren't intended to be accessed by other parts. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Regoin Screen n Framebufer
On Thu, 18 Jul 2002, Preetham wrote: > Thanx Mark, > Before i get to clarifying what my last question in the prev mail was > about, i have another > doubt. > I was reading thru the server architecture document and came accross the > Shadow FB Engine. > "The Shadow FB engines use Keith Packard's FB drawing procedures wrapped > with his Shadow layer that allows drawing to an offscreen framebuffer > with periodic updates of the primary framebuffer." > What i understood by this is, i can create a copy of the framebuffer in > the memory(possibly save it to the hard drive) and use it like a windows > bitmap. This bitmap will have the image of the screen(Eg: a linux > desktop equivalent to a windows desktop snapshot). The shadowfb wraps rendering functions and tells you which parts of the framebuffer has been updated. The common usage is to put the framebuffer (what all the rendering code thinks is the framebuffer) in system memory so that all rendering goes into that. Shadowfb's callbacks telling you which parts have been modified would allow you to copy those parts from the system memory buffer to another buffer (such as a video ram buffer) keeping those two buffers in sync. However, since the X-server is now rendering in system memory you have eliminated the possibilty of hardware acceleration. You could do just the opposite though, and have shadowfb wrap rendering into the video ram framebuffer and you could get informed of modified areas. A layer that did this could probably be installed as an extension module and work with all drivers without any modifications to the core X-server binary. > What i meant by my last question was: If my preveious inference is > correct, then can i use this > Shadow Engine, or write an engine of my own that would capture the > graphic information of only the active window(top level window) of the > screen. > What i am looking to do is, open an appication and only capture the > graphics related to the > window the application opens. You could modify shadowfb to inform you only about updates to particular windows, yes. Well, a corner case is when somebody draws on a parent of that window with IncludeInferiors, for example when the window manager draws XOR'd lines on the root window when placing windows. If you just trapped for actions on your window you wouldn't see that, but it may be that you're not interested in capturing that. Other corner cases are that you won't know about OpenGL rendering because it would be direct rendered by the client without X-server involvement. What is the intended purpose? Are you trying to monitor particular windows remotely? Was the idea to have the X-server notify when there was new data and provide minimum updates or something? Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Setting up MTRR support
On Fri, 19 Jul 2002, Peter Finderup Lund wrote: > > lspci: > 01:00.0 VGA compatible controller: nVidia Corporation Riva TNT2 Model 64 > (rev 15) (prog-if 00 [VGA]) > Subsystem: AOPEN Inc.: Unknown device 000d > Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 9 > Memory at e400 (32-bit, non-prefetchable) > Memory at e600 (32-bit, prefetchable) > Expansion ROM at e500 [disabled] > Capabilities: [60] Power Management version 1 > Capabilities: [44] AGP version 2.0 > > If anybody knows why my card also shows up twice in the memory map I'd be > much obliged. Is the first (non-prefetchable) part memory-mapped control > registers for the accellerator functions and the second one the > framebuffer? > The non-prefectable is registers, the prefecthable is framebuffer. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]pan locking / sroll locking the viewport in X
On Thu, 18 Jul 2002 [EMAIL PROTECTED] wrote: > > On Wed, 17 Jul 2002, Christopher A Len wrote: > > > > > Is there a way to lock the viewport from panning to other areas of the > > > virtual desktop? Normally, I run 1152x864 desktop and 1152x864 viewport. > > > However, I want to be able to zoom in on a window (eg change viewport to > > > 640x480 or 800x600), and keep the viewport from scrolling when the pointer > > > hits the screen edge. Is there a way to do this? I tried scroll lock, it > > > had no effect. My keyboard map is us104. Any feedback would be > > > appreciated. I cant imagine something like this hasn't been implemented > > > yet... > > > > > > >We've discussed this years ago. It's possibly not difficult to > > implement either. Nobody seemed to care enough about it to do this > > though. Somebody would have to care enough about it to volunteer > > to do the work. You perhaps? > > I actually had this working in my tree at home a couple of years ago. > That is, I could move the viewport, press ScrollLock, and then the viewport > was locked in that position until ScrollLock was pressed again. There > were some complications though: > > 1) There needed to be a way to configure which key controlled the viewport lock > > 2) A client-side interface would have been useful. For example, a window manager > could receive an event when the viewport was locked and remap the positions of > windows to fit within the visable viewport. Or it could have initiated the > viewport lock. Maybe allowing a client to enable/disable the effect of the > ScrollLock key would have been nice. > > 3) How do you mix it with Xinerama or even plain multi-head configs? Should > moving the mouse to the edge of the viewport trigger a switch to another screen? > It's not clear what the best behavior is. Also, when one modeswitches, that modeswitch goes into effect on the head the pointer is on at that time. The Scroll-lock key, however, would imply a global action, not a head-specific action. Maybe another hotkey would be better than the scroll-lock key. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]USB Keypad
I want to simultaneously use a PS/2 keyboard (This is a laptop, so switching that out is not an option) and a USB numeric keypad, which works perfectly as a usb HID keyboard. Is there any way to do this with the current keyboard driver ? -- Josh Litherland ([EMAIL PROTECTED]) public key: temp123.org/fauxpas.pgp fingerprint: CFF3 EB2B 4451 DC3C A053 1E07 06B4 C3FC 893D 9228 ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Regoin Screen n Framebufer
Thanx Mark, Before i get to clarifying what my last question in the prev mail was about, i have another doubt. I was reading thru the server architecture document and came accross the Shadow FB Engine. "The Shadow FB engines use Keith Packard's FB drawing procedures wrapped with his Shadow layer that allows drawing to an offscreen framebuffer with periodic updates of the primary framebuffer." What i understood by this is, i can create a copy of the framebuffer in the memory(possibly save it to the hard drive) and use it like a windows bitmap. This bitmap will have the image of the screen(Eg: a linux desktop equivalent to a windows desktop snapshot). What i meant by my last question was: If my preveious inference is correct, then can i use this Shadow Engine, or write an engine of my own that would capture the graphic information of only the active window(top level window) of the screen. What i am looking to do is, open an appication and only capture the graphics related to the window the application opens. Thanks, Preetham. Mark Vojkovich wrote: >On Thu, 18 Jul 2002, Preetham wrote: > >>> Be careful. A "Display" in X-Window terminology is a connection to >>>the X-server. A single client can open many "Display" connections all >>>to the same screen. It's a "screen" that indicates a framebuffer. >>> >>Correct me if i am wrong: >> > > You are wrong. > >>1.What you mean to say is: >>Display is a connection to a screen, and all clients that share the display, >>write graphics >>information to the same screen. >> > > A "Display" in Xlib is a connection to a server. A Display is >exclusive to a client. A client can use that Display to render to >any Screen on the X-Server. A "Display" is an opaque handle within >the client's namespace. Actually, my comment about a single client >opening many Display connections was inaccurate. What I meant to >say was that a process may open as many Display connections as it >wants. Each Display connection is essentially a different client >and the X-server has no way of knowing that two particular clients >are really the same process. Basically, client == Display connection. >An app that opens a Display and uses a toolkit that also opens a >display is actually two clients. The X-server does not know that >they are the same application. > > >>2. So, each X-Server can have only one framebuffer. >> > > Each X-server can have as many framebuffers (screens) as it wants. >The #define limit in XFree86 is 32, but only 16 have been tested. >There is one special case (Xinerama) where multiple framebuffers are >used to make up one screen from the client's point of view. > >>3.If i create a seperate buffer(one for each client, not a consolidated >>screen), >>is it possible to modify the XServer to capture the graphics generated by >>each >>of the clients and write them into their corresponding buffers. >> > > I don't understand what you have described there. There is >only one framebuffer per screen. The concept of a separate buffer >per client doesn't make sense. While particular operations are >associated with a client some are not. Painting of a window background >for instance may be instigated by movement of another window without >any action initiating it by the client who created painted window. Also, >a client can render into a window it didn't create. Any drawable, >regardless of who created it is fair game for any client. And the >root window isn't owned by any client - it is owned by the X-server. > > Perhaps if you would explain what it is that you are trying to >do. > > > Mark. > ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Setting up MTRR support
On Thu, 18 Jul 2002, Andy Isaacson wrote: > > Doesn't work here. If I do "cat /proc/mtrr" before running an X-server I > > get nothing at all: > > "" > > Ah, perhaps your CPU only has 1 MTRR. You could check the kernel code > if you're very curious. The AMD K6-2 has two (I was curious some months ago and read the documentation from AMD). > > Running "cat /proc/mtrr" after starting the X server gives me the > > following: > > > > reg00: base=0xd000 (3328MB), size= 32MB: write-combining, count=1 > > That looks a whole lot like a framebuffer. So what's the point of this > thread, then, if it's working fine for you? :) (I came in at the tail > end here, sorry if I'm missing context.) It probably is his framebuffer. What troubles him, I think, is that lspci tells him that the video card has two memory ranges and only one of them is covered by an MTRR. I have an AMD K6-2 500 MHz and a RIVA TNT2 M64 card. I'm running Linux 2.2.21 and XFree86 4.2.0. cat /proc/mtrr: reg00: base=0xe600 (3680MB), size= 32MB: write-combining, count=1 lspci: 01:00.0 VGA compatible controller: nVidia Corporation Riva TNT2 Model 64 (rev 15) (prog-if 00 [VGA]) Subsystem: AOPEN Inc.: Unknown device 000d Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 9 Memory at e400 (32-bit, non-prefetchable) Memory at e600 (32-bit, prefetchable) Expansion ROM at e500 [disabled] Capabilities: [60] Power Management version 1 Capabilities: [44] AGP version 2.0 If anybody knows why my card also shows up twice in the memory map I'd be much obliged. Is the first (non-prefetchable) part memory-mapped control registers for the accellerator functions and the second one the framebuffer? (I think I used to know this... :/ ) -Peter ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Read window of focus info in DDX layer
On Thu, 18 Jul 2002, Annie Luo wrote: > > > > > x = inputInfo.keyboard->focus->win->origin.x; > > > > > y = inputInfo.keyboard->focus->win->origin.y; > > >I believe that holds the window that keyboard events are going > > into, but that's one of the areas of the server that I know the > > least about. The origin there is relative to that window's parent. > > Thanks Mark. What is strange is that the two short int values > > inputInfo.keyboard->focus->win->origin.x > inputInfo.keyboard->focus->win->origin.y > > are not even readable. The original declaration of InputInfo is a Register, > do you think this relative to the problem I met? > I don't know what you mean by them not being readable. It may be possible that there is no focus and win is null, but I don't know anything about those implementation details. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]pan locking / sroll locking the viewport in X
> On Wed, 17 Jul 2002, Christopher A Len wrote: > > > Is there a way to lock the viewport from panning to other areas of the > > virtual desktop? Normally, I run 1152x864 desktop and 1152x864 viewport. > > However, I want to be able to zoom in on a window (eg change viewport to > > 640x480 or 800x600), and keep the viewport from scrolling when the pointer > > hits the screen edge. Is there a way to do this? I tried scroll lock, it > > had no effect. My keyboard map is us104. Any feedback would be > > appreciated. I cant imagine something like this hasn't been implemented > > yet... > > > >We've discussed this years ago. It's possibly not difficult to > implement either. Nobody seemed to care enough about it to do this > though. Somebody would have to care enough about it to volunteer > to do the work. You perhaps? I actually had this working in my tree at home a couple of years ago. That is, I could move the viewport, press ScrollLock, and then the viewport was locked in that position until ScrollLock was pressed again. There were some complications though: 1) There needed to be a way to configure which key controlled the viewport lock 2) A client-side interface would have been useful. For example, a window manager could receive an event when the viewport was locked and remap the positions of windows to fit within the visable viewport. Or it could have initiated the viewport lock. Maybe allowing a client to enable/disable the effect of the ScrollLock key would have been nice. 3) How do you mix it with Xinerama or even plain multi-head configs? Should moving the mouse to the edge of the viewport trigger a switch to another screen? I never really did anything about any of those and never submitted the changes to the patch queue. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Regoin Screen n Framebufer
On Thu, 18 Jul 2002, Preetham wrote: > >Be careful. A "Display" in X-Window terminology is a connection to > > the X-server. A single client can open many "Display" connections all > > to the same screen. It's a "screen" that indicates a framebuffer. > Correct me if i am wrong: You are wrong. > 1.What you mean to say is: > Display is a connection to a screen, and all clients that share the display, > write graphics > information to the same screen. A "Display" in Xlib is a connection to a server. A Display is exclusive to a client. A client can use that Display to render to any Screen on the X-Server. A "Display" is an opaque handle within the client's namespace. Actually, my comment about a single client opening many Display connections was inaccurate. What I meant to say was that a process may open as many Display connections as it wants. Each Display connection is essentially a different client and the X-server has no way of knowing that two particular clients are really the same process. Basically, client == Display connection. An app that opens a Display and uses a toolkit that also opens a display is actually two clients. The X-server does not know that they are the same application. > 2. So, each X-Server can have only one framebuffer. Each X-server can have as many framebuffers (screens) as it wants. The #define limit in XFree86 is 32, but only 16 have been tested. There is one special case (Xinerama) where multiple framebuffers are used to make up one screen from the client's point of view. > 3.If i create a seperate buffer(one for each client, not a consolidated > screen), > is it possible to modify the XServer to capture the graphics generated by > each > of the clients and write them into their corresponding buffers. I don't understand what you have described there. There is only one framebuffer per screen. The concept of a separate buffer per client doesn't make sense. While particular operations are associated with a client some are not. Painting of a window background for instance may be instigated by movement of another window without any action initiating it by the client who created painted window. Also, a client can render into a window it didn't create. Any drawable, regardless of who created it is fair game for any client. And the root window isn't owned by any client - it is owned by the X-server. Perhaps if you would explain what it is that you are trying to do. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Setting up MTRR support
On Thu, Jul 18, 2002 at 08:09:27PM -0500, Markus Glodek wrote: > > On startup, before X has ever run, do a "cat /proc/mtrr". You should > > see a single MTRR the size of your memory, like so: > > > > reg00: base=0x ( 0MB), size= 256MB: write-back, count=1 > > Doesn't work here. If I do "cat /proc/mtrr" before running an X-server I > get nothing at all: > "" Ah, perhaps your CPU only has 1 MTRR. You could check the kernel code if you're very curious. > Running "cat /proc/mtrr" after starting the X server gives me the > following: > > reg00: base=0xd000 (3328MB), size= 32MB: write-combining, count=1 That looks a whole lot like a framebuffer. So what's the point of this thread, then, if it's working fine for you? :) (I came in at the tail end here, sorry if I'm missing context.) > I do not seem to be able to modify this entry with > > "echo "base=0xd900 size=0x200 type=write-combining" >| /proc/mtrr" Consistent with having only one MTRR. Try deleting that one and then see if you can add another. > > Additionally, you can look at the XFree86 log file, > > Can't find anything about MTRR in "XFree86.0.log". I included a copy of > the file in my first post. Sorry, in my log it looks like this: (==) NV(0): Write-combining range (0xd400,0x100) and (==) MGA(0): Write-combining range (0xd800,0x200) (different machines, obviously.) > Any ideas on how get MTRR set up under these circumstances? [checks back up the thread] It looks to me like xine-check is using some invalid method of checking for MTRR support. It looks to me like your MTRR support is working just fine. Yep, it even shows up in your XFree86.0.log file. Dunno what's wrong with xine-check; does xine itself work OK? You should report this to the xine folks. See ya over on xine-user. :) -andy ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Read window of focus info in DDX layer
> > > > x = inputInfo.keyboard->focus->win->origin.x; > > > > y = inputInfo.keyboard->focus->win->origin.y; >I believe that holds the window that keyboard events are going > into, but that's one of the areas of the server that I know the > least about. The origin there is relative to that window's parent. Thanks Mark. What is strange is that the two short int values inputInfo.keyboard->focus->win->origin.x inputInfo.keyboard->focus->win->origin.y are not even readable. The original declaration of InputInfo is a Register, do you think this relative to the problem I met? ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Setting up MTRR support
Many thanks for the response. > False. Using a write-combining MTRR helps performance on PCI as well as > AGP. I actually have an AGP card (ATI Radeon7000) > > On startup, before X has ever run, do a "cat /proc/mtrr". You should > see a single MTRR the size of your memory, like so: > > reg00: base=0x ( 0MB), size= 256MB: write-back, count=1 Doesn't work here. If I do "cat /proc/mtrr" before running an X-server I get nothing at all: "" > Then, start X. In an xterm, do "cat /proc/mtrr". You should see some > more mtrr entries there. Here's mine: > > reg00: base=0x ( 0MB), size= 256MB: write-back, count=1 > reg01: base=0xd400 (3392MB), size= 16MB: write-combining, count=1 > reg05: base=0xd000 (3328MB), size= 64MB: write-combining, count=1 Running "cat /proc/mtrr" after starting the X server gives me the following: reg00: base=0xd000 (3328MB), size= 32MB: write-combining, count=1 I do not seem to be able to modify this entry with "echo "base=0xd900 size=0x200 type=write-combining" >| /proc/mtrr" When I do another "cat /proc/mtrr", I simply get the same as before: reg00: base=0xd000 (3328MB), size= 32MB: write-combining, count=1 > Additionally, you can look at the XFree86 log file, Can't find anything about MTRR in "XFree86.0.log". I included a copy of the file in my first post. Any ideas on how get MTRR set up under these circumstances? Thanks, Markus ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Regoin Screen n Framebufer
>Be careful. A "Display" in X-Window terminology is a connection to > the X-server. A single client can open many "Display" connections all > to the same screen. It's a "screen" that indicates a framebuffer. Correct me if i am wrong: 1.What you mean to say is: Display is a connection to a screen, and all clients that share the display, write graphics information to the same screen. 2. So, each X-Server can have only one framebuffer. 3.If i create a seperate buffer(one for each client, not a consolidated screen), is it possible to modify the XServer to capture the graphics generated by each of the clients and write them into their corresponding buffers. Appreciate the help thanks, Preetham - Original Message - From: "Mark Vojkovich" <[EMAIL PROTECTED]> To: "Preetham" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, July 18, 2002 2:02 PM Subject: Re: [Xpert]Regoin Screen n Framebufer > On Thu, 18 Jul 2002, Preetham wrote: > > > Thanx Mark, > > 1. In windows(OS), there is only one console session running, and hence > > effectively only > > one frame buffer. However in Linux we can multiple displays indentified by > > display > > numbers. Do each of the Displays have a framebuffer assosciated with them. > >Be careful. A "Display" in X-Window terminology is a connection to > the X-server. A single client can open many "Display" connections all > to the same screen. It's a "screen" that indicates a framebuffer. > > > > > 2. If there are 5 windows open in a Display:0, who is responsible for > > writing the display > > information generated by the windows into the Linux Framebufer(for > > display0).. > >I'm not sure I understand the question. I don't know what you mean > by "display information generated by the windows". > > > > > 3. Is the region viewed at a window(of an application) level or at the > > screen level. > >You mean the coordinate system? The coordinates in the region are > relative to the screen (Root Window). > > > Mark. > > > ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Setting up MTRR support
On Thu, Jul 18, 2002 at 06:30:42PM -0500, Markus Glodek wrote: > > > [ hint ] you have MTRR support but it's unused. > > > It seems like your X server didn't set any MTRR ranges for the > > > graphics card. Maybe upgrading your X server helps... > > > You don't have a PCI graphics card, do you? AFAIK, MTRR only > > > helps with AGP cards. False. Using a write-combining MTRR helps performance on PCI as well as AGP. > > Are you sure you have MTRR support in your kernel? > > > > cat /var/log/messages | grep -i "mtrr" grep -i mtrr /var/log/messages. Useless Use of Cat award! > > gives me (Matrox gfx card): > > > > Jul 18 22:56:03 spookcentral kernel: mtrr: v1.40 (20010327) Richard Gooch > > ([EMAIL PROTECTED]) > > Jul 18 22:56:03 spookcentral kernel: mtrr: detected mtrr type: Intel > > Jul 18 22:56:03 spookcentral kernel: matroxfb: MTRR's turned on This line is only present because you have a Matrox card and are using the matroxfb module. Non-Matrox cards, or people who don't use matroxfb, won't see it. > Jul 18 10:04:58 philo kernel: mtrr: v1.40 (20010327) Richard Gooch > ([EMAIL PROTECTED]) > Jul 18 10:04:58 philo kernel: mtrr: detected mtrr type: AMD K6 > > Nothing about "MTRR's turned on". I thought that the mere presence of > /proc/mtrr (it's there) tells me that my kernel supports MTRR. Does it? > > What should I do? On startup, before X has ever run, do a "cat /proc/mtrr". You should see a single MTRR the size of your memory, like so: reg00: base=0x ( 0MB), size= 256MB: write-back, count=1 Then, start X. In an xterm, do "cat /proc/mtrr". You should see some more mtrr entries there. Here's mine: reg00: base=0x ( 0MB), size= 256MB: write-back, count=1 reg01: base=0xd400 (3392MB), size= 16MB: write-combining, count=1 reg05: base=0xd000 (3328MB), size= 64MB: write-combining, count=1 Those write-combining entries indicate that the framebuffer has been mapped. Additionally, you can look at the XFree86 log file, /var/log/XFree86.0.log. Search for MTRR. (Case insensitive, I suppose.) -andy ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Setting up MTRR support
Many thanks for the response. cat /var/log/messages | grep -i "mtrr" gives me Jul 18 10:04:58 philo kernel: mtrr: v1.40 (20010327) Richard Gooch ([EMAIL PROTECTED]) Jul 18 10:04:58 philo kernel: mtrr: detected mtrr type: AMD K6 Nothing about "MTRR's turned on". I thought that the mere presence of /proc/mtrr (it's there) tells me that my kernel supports MTRR. Does it? What should I do? Thanks. > > [ hint ] you have MTRR support but it's unused. > > It seems like your X server didn't set any MTRR ranges for the > > graphics card. Maybe upgrading your X server helps... > > You don't have a PCI graphics card, do you? AFAIK, MTRR only > > helps with AGP cards. > > press to continue... > > Are you sure you have MTRR support in your kernel? > > cat /var/log/messages | grep -i "mtrr" > > gives me (Matrox gfx card): > > Jul 18 22:56:03 spookcentral kernel: mtrr: v1.40 (20010327) Richard Gooch > ([EMAIL PROTECTED]) > Jul 18 22:56:03 spookcentral kernel: mtrr: detected mtrr type: Intel > Jul 18 22:56:03 spookcentral kernel: matroxfb: MTRR's turned on ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Fine-tuning NM2160 acceleration?
On Sat, 2002-07-13 at 12:01, Steve Snyder wrote: > > Can I enable/disable specific acceleration features rather that the blanket > use/disuse of 'Option "NoAccel"'? There are many things that contribute to > hardware-accelerated video. I'm willing to experiment to find out exactly > which one(s) is causing my lockups. I'm hoping I can get a list of of > which "XaaNo..." features actually compose the NoAccel option. Well, all of them. :) That is, actually only those which disable the accelerated functions of the driver of course. They are listed after the line (II) RADEON(0): Using XFree86 Acceleration Architecture (XAA) in the log. -- 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]Is the XFree development stuck in a dead end?
On 15 Jul, this message from [EMAIL PROTECTED] echoed through cyberspace: [snip] > Perhaps there would be value to a motion rate limiting option in the X > server. This is not merely covering up for flawed applications. In the > current environment, a fast application can respond to the XMotionEvent > faster than the events are sent. So the fast application is performing > the cycle of read an event, update the screen, and returning to read > another event several times per screen refresh. This is waste motion > and interferes with scheduler logic. It would make sense to specify to > the X server that it should combine motion events for 10-20 milliseconds > before sending another motion event. This avoids all the scheduling and > messaging traffic during that invisible interval. Hmm... sync the events to a VBL interrupt? 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]Regoin Screen n Framebufer
On Thu, 18 Jul 2002, Preetham wrote: > Thanx Mark, > 1. In windows(OS), there is only one console session running, and hence > effectively only > one frame buffer. However in Linux we can multiple displays indentified by > display > numbers. Do each of the Displays have a framebuffer assosciated with them. Be careful. A "Display" in X-Window terminology is a connection to the X-server. A single client can open many "Display" connections all to the same screen. It's a "screen" that indicates a framebuffer. > > 2. If there are 5 windows open in a Display:0, who is responsible for > writing the display > information generated by the windows into the Linux Framebufer(for > display0).. I'm not sure I understand the question. I don't know what you mean by "display information generated by the windows". > > 3. Is the region viewed at a window(of an application) level or at the > screen level. You mean the coordinate system? The coordinates in the region are relative to the screen (Root Window). Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]TinyXserver framebuffer
MN> 1. I cannot find which module (section of code/file) xserver uses to write MN> data to the framebuffer after Pixblit routines. Where exactly does xserver MN> write to framebuffer array? That's the code in Xserver/fb. See KdScreenInit in kdrive.c which sets up the Screen's methods with a blend of fb, mi and kd functions. Juliusz ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Setting up MTRR support
Yello On Thu, 18 Jul 2002 15:40:36 -0500 (CDT) Markus Glodek <[EMAIL PROTECTED]> wrote: > I am completely new to Linux, so please bear with me. I am trying to > speed up DVD playback under Xine. > "xine-check" gives me the following information: > > [ hint ] you have MTRR support but it's unused. > It seems like your X server didn't set any MTRR ranges for the > graphics card. Maybe upgrading your X server helps... > You don't have a PCI graphics card, do you? AFAIK, MTRR only > helps with AGP cards. > press to continue... Are you sure you have MTRR support in your kernel? cat /var/log/messages | grep -i "mtrr" gives me (Matrox gfx card): Jul 18 22:56:03 spookcentral kernel: mtrr: v1.40 (20010327) Richard Gooch ([EMAIL PROTECTED]) Jul 18 22:56:03 spookcentral kernel: mtrr: detected mtrr type: Intel Jul 18 22:56:03 spookcentral kernel: matroxfb: MTRR's turned on -- Mvh. / Kind regards Henrik Farre http://www.cs.auc.dk/~enrique http://www.fsf.org/philosophy/no-word-attachments.html ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]S3 Graphics Twister K Compaq
>> > Does anybody know what shall I do to get my S3 Graphics Twister K Compaq >> > card to work in XF86? KB> And the Savage driver web page is at: KB> http://www.probo.com/timr/savage40.html The important thing: as far as I know, no automatic configuration tools recognise the Twister K. After installing Tim's latest driver, you should manually configure XFree86 for *any* Savage card, and the driver will deal with the rest. While it doesn't directly apply to your machine, you may find the following collection of random information useful: http://www.pps.jussieu.fr/~jch/software/presario/ Juliusz ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Problem regarding configuration of 2 display cards
Hi List, we have two machines with identical software environments but little difference in the hardware configuration. Hardware configuration differs as following: Machine1Machine2 Motherboard:SUPER P6SBA MS-6309 ATX VA5 motherboard Display card 1: ATI RADEON (AGP)ATI RADEON (AGP) Display Card 2: ATI Rage XL (PCI) ATI Rage XL (PCI) We connect a projector to the DVI port of ATI RADEON(AGP Card) and monitor (NEC LCD1530V) to ATI Rage XL (PCI) card. Primary card is set to AGP in BIOS. We have the same configuration file, XF86Config-4 on both the machines. This config file only has entries to config the Rage card. We config the AGP Radeon card using the vesafb driver. Our problem : On machine1, when we try to run Xwindows, we get following Error message: (II) Primary Device is: PCI:01:00:00 /* this is right */ (II) ATI: Candidate \"Device\" section \"ATI Rage XL\" /* this is fine */ (WW) ATI: PCI/AGP Mach64 in slot 0:15:0 could not be detected (WW) ATI: PCI/AGP Mach64 in slot 1:00:0 could not be detected (EE) No Devices detected whereas on machine2 which has almost same configuration, it works absolutely fine. Please let us know where should we look to solve this problem, what could be the probable solution? Thanks in advance, Regards, Vikram B, Jing Xu Graduate Students - CS Dept University of New Mexico ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Setting up MTRR support
I am completely new to Linux, so please bear with me. I am trying to speed up DVD playback under Xine. "xine-check" gives me the following information: [ hint ] you have MTRR support but it's unused. It seems like your X server didn't set any MTRR ranges for the graphics card. Maybe upgrading your X server helps... You don't have a PCI graphics card, do you? AFAIK, MTRR only helps with AGP cards. press to continue... It seems that I have to set MTRR ranges for my graphics card (ATI Radeon700, and an AMD K6-2). I am told that I need to first determine the memory base address of the graphics card by looking at XFree86.0.log. I take it that this is the relevant line from XFree86.0.log: (--) PCI:*(1:0:0) ATI Radeon VE QY rev 0, Mem @ 0xd000/27, 0xd900/16, I/O @ 0xc000/8 >From this I take it that the memory base address for my graphics card is 0xd900. Is this correct? Also, my graphics card has 32MB RAM, which is in Hex: 0x200. Correct so far? With these values, I do the following: # cat /proc/mtrr reg00: base=0xd000 (3328MB), size= 32MB: write-combining, count=1 # echo "base=0xd900 size=0x200 type=write-combining" >| /proc/mtrr # cat /proc/mtrr reg00: base=0xd000 (3328MB), size= 32MB: write-combining, count=1 Something seems to have gone wrong, no? Shouldn't the output of the second "cat /proc/mtrr" be different from the output of the first one? Can anyone explain to me what is going wrong, and what I have to do to set the correct MTRR ranges? Thanks a lot, Markus PS: Here is my XFree86.0.log, in case something is wrong with the memory base address I am trying to use: XFree86 Version 4.2.0 (Red Hat Linux release: 4.2.0-8) / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 23 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.4.17-0.13smp i686 [ELF] Build Host: daffy.perf.redhat.com 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: Thu Jul 18 10:07:17 2002 (==) Using config file: "/etc/X11/XF86Config-4" (==) ServerLayout "Anaconda Configured" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "ATI Radeon 7000" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard0" (**) Option "XkbRules" "xfree86" (**) XKB: rules: "xfree86" (**) Option "XkbModel" "pc105" (**) XKB: model: "pc105" (**) Option "XkbLayout" "us" (**) XKB: layout: "us" (==) 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.5 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.0, 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.0, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.5 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x8060, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 1106,0598 card , rev 04 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 1106,8598 card , rev 00 class 06,04,00 hdr 01 (II) PCI: 00:07:0: chip 1106,0586 card 1106, rev 47 class 06,01,00 hdr 80 (II) PCI: 00:07:1: chip 1106,0571 card , rev 06 class 01,01,8a hdr 00 (II) PCI: 00:07:2: chip 1106,3038 card 0925,1234 rev 02 class 0c,03,00 hdr 00 (II) PCI: 00:07:3: chip 1106,3040 card , rev 10 class 06,00,00 hdr 00 (II) PCI: 00:08:0: chip 12b9,1008 card 12b9,00d7 rev 01 class 07,00,02 hdr 00 (II) PCI: 00:09:0: chip 10ec,8139 card 10ec,8139 rev 10 class 02,00,00 hdr 00 (II) PCI: 00:0a:0: chip 1274,1371 card 1274,1371 rev 08 class 04,01,00 hdr 00 (II) PCI: 01:00:0: chip 1002,5159 card 1002,000a 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.0, module version = 0.1.0
Re: [Xpert]Regoin Screen n Framebufer
Thanx Mark, 1. In windows(OS), there is only one console session running, and hence effectively only one frame buffer. However in Linux we can multiple displays indentified by display numbers. Do each of the Displays have a framebuffer assosciated with them. 2. If there are 5 windows open in a Display:0, who is responsible for writing the display information generated by the windows into the Linux Framebufer(for display0).. 3. Is the region viewed at a window(of an application) level or at the screen level. Appreciate the help. Thanx, Preetham. Is there one frame buffer associated with one display. - Original Message - From: "Mark Vojkovich" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, July 18, 2002 12:08 PM Subject: Re: [Xpert]Regoin Screen n Framebufer > On Thu, 18 Jul 2002, Preetham wrote: > > > Hi all, > > I was going thru the docs and found a reference to a regoin. What > > exactly constitutes a region in a framebuffer. > >A Region is essentially a list of rectangles. See: > xc/programs/Xserver/include/regionstr.h > > > > Also, is there any information i could get on the Xserver\miext\shadow > > files. Is it to create another shadow frame buffer that other programs > > can read from. > > >I wrote the original shadowfb in xc/programs/Xserver/hw/xfree86/shadowfb. > Basically what it does is wraps all rendering functions and gives the > initializer a callback indicating that the framebuffer was touched and > reports a bounding box around the damaged area. This was written to > get X working on the 3Dfx Voodoo 1 and 2 cards. The idea was that > you could create a proxy framebuffer in system memory for the server > to render into, trap rendering into it with the shadow framebuffer layer > and then copy bounding regions from it into the real framebuffer. > This would allow running X on hardware that had complicated access > to the framebuffer. > >Keith Packard wrote the improved version that you are asking about. > It gives finer detail in its callback. It reports a region rather > than a bounding box. It also has a performance advantage that it > doesn't report after every access to the framebuffer, but rather > coaleses groups of requests and reports them when the X-server > goes back to waiting on its file descriptors. This is roughly > every 20 milliseconds or so. > > The generic use of the shadowfb is just to notify of changes > to windows and the original shadowfb code can do that. I'm not > sure if the new stuff is that generic anymore or if stuff has > creap into it that solidifies it with the intent of proxy > framebuffer operation, but if you have a custom project it probably > wouldn't be too much trouble to modify this for your needs. > > > Mark. > ___ > Xpert mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XVideo extension docs
On Thu, 18 Jul 2002, Guido Fiala wrote: > >API docs are in the server tree at xc/doc/hardcopy/Xv. There > >are DEC's original docs there and the version 2.2 addendum. > > Thanks too. > However - that does'nt seem to be more than just the man-pages. > > I'am missing documentation about the XV_FREQ atom - what is the purpose and > unit of the freq interger? These are all driver-specific properties and not something that would be in a general API description. For the most part these just shadow the V4L attributes. > (It seems anything works the same with and without setting that at all) > Also - i don't see why i should use the Put/GetVideo calls at all, they don't > seem to do anything useful for me. > > Another thing - where are the number of available _input_ formats (color > spaces) specified? > I mean - why are just those available listed by xvinfo and not e.g. RGB565 > or RGB24 which would give much better output quality than YUV2 from v4l > devices!? Are you speaking of XvImage formats or something else? XvImage formats are formats the hardware supports. There are no software fallbacks in any Xv drivers that I've seen, so if the hardware doesn't do it, it doesn't get advertised. Video is not in RGB. Video is always in YUV. I don't think it's possible for an RGB format to have better quality if the video source is in YUV. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Xlib extension missing...
On Thu, 18 Jul 2002, Carlos Luna wrote: > Hi! > > I am using xawtv to view my quickcam webcamera and at startup it says this: > This is xawtv-3.74, running on Linux/i586 (2.4.18) > Xlib:extension "XVideo" missing on display ":0.0". > ... > > Any ideas of what XVideo is and does? > Is it important to view video images? X-Video is an X-server extension that provides functions for hardware colorspace conversion and scaling, also it can provide mechanisms to get images from video devices into a window. Most of these are hardware-specific features and the X-Video extension's presence depends on drivers. Running the "xvinfo" program that comes with XFree86 will report the X-Video capabilities of the X-Server. I believe xawtv can operate without it, but in a hackish sort of way. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Regoin Screen n Framebufer
On Thu, 18 Jul 2002, Preetham wrote: > Hi all, > I was going thru the docs and found a reference to a regoin. What > exactly constitutes a region in a framebuffer. A Region is essentially a list of rectangles. See: xc/programs/Xserver/include/regionstr.h > Also, is there any information i could get on the Xserver\miext\shadow > files. Is it to create another shadow frame buffer that other programs > can read from. I wrote the original shadowfb in xc/programs/Xserver/hw/xfree86/shadowfb. Basically what it does is wraps all rendering functions and gives the initializer a callback indicating that the framebuffer was touched and reports a bounding box around the damaged area. This was written to get X working on the 3Dfx Voodoo 1 and 2 cards. The idea was that you could create a proxy framebuffer in system memory for the server to render into, trap rendering into it with the shadow framebuffer layer and then copy bounding regions from it into the real framebuffer. This would allow running X on hardware that had complicated access to the framebuffer. Keith Packard wrote the improved version that you are asking about. It gives finer detail in its callback. It reports a region rather than a bounding box. It also has a performance advantage that it doesn't report after every access to the framebuffer, but rather coaleses groups of requests and reports them when the X-server goes back to waiting on its file descriptors. This is roughly every 20 milliseconds or so. The generic use of the shadowfb is just to notify of changes to windows and the original shadowfb code can do that. I'm not sure if the new stuff is that generic anymore or if stuff has creap into it that solidifies it with the intent of proxy framebuffer operation, but if you have a custom project it probably wouldn't be too much trouble to modify this for your needs. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XVideo extension docs
>API docs are in the server tree at xc/doc/hardcopy/Xv. There >are DEC's original docs there and the version 2.2 addendum. Thanks too. However - that does'nt seem to be more than just the man-pages. I'am missing documentation about the XV_FREQ atom - what is the purpose and unit of the freq interger? (It seems anything works the same with and without setting that at all) Also - i don't see why i should use the Put/GetVideo calls at all, they don't seem to do anything useful for me. Another thing - where are the number of available _input_ formats (color spaces) specified? I mean - why are just those available listed by xvinfo and not e.g. RGB565 or RGB24 which would give much better output quality than YUV2 from v4l devices!? ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]SendCoreEvents vs. CorePointer and xmodmap
Hello, I've discovered the following interesting and unfortunate behaviour in 4.2.0: The pointer declared as CorePointer is, as expected, affected by 'xmodmap -e "pointer = foo"', but pointers declared as SendCoreEvents are not. This is easily reproducible. It makes it impossible for me to use all the buttons on my 5-button+wheel USB mouse unless I make it the CorePointer, in which case of course X won't start if it's not attached. Is there a way around this? - Alan ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Automatically copying selection
On Wed, 17 Jul 2002, y wrote: > When I select text it automatically copies it to the clipboard. > While a lot of people love this feature, I just hate it. > People sometime select text to delete it, for example (especially in GUI > editors). > > Could you tell me how to disable it, or is it hopeless? I think it is hopeless :( It's too deeply built into the X architecture to change for all clients - it's not just a question of setting a boolean flag to another value. Some clients and toolkits, however, have workarounds so the behaviour might end up being closer to your liking. Background info: (I hope I got the details right - it's complex stuff) There isn't one entity that you could call the clipboard in X, there are several. One set of those are the cut buffers, another are the selections. Cut buffers have numbers and selections have names. Usually cut buffer #0 and the selections PRIMARY and CLIPBOARD are used. When you select paste in an application, some toolkits will paste from PRIMARY first, if it is non-empty, and try CLIPBOARD next -- I think. Others will always use PRIMARY if you paste with the middle button and CLIPBOARD if you select paste from a menu or use a keyboard shortcut. The buffer for the CLIPBOARD selection gets overwritten only when you actually select copy in the application (and PRIMARY also gets written). When you select something (before the delete/copy/cut) only the PRIMARY selection gets overwritten. (there is also a standard selection called SECONDARY, just to make things more complicated - but few use that) You can read almost the whole story here: http://www.freedesktop.org/standards/clipboards.txt if you are really curious you can always check the three references at the bottom. KDE 2.x applications didn't quite follow the above standard but current KDE and Gnome apps do. Many applications not made with either won't. -Peter ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]What happened to xc/lib/GL/mesa/dri ?
On Thu, 2002-07-18 at 17:51, Johannes Rath wrote: > I just downloaded the latest CVS and noticed xc/lib/GL/mesa/dri is empty. > Any reason for this? It moved to xc/lib/GL/dri . -- 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]X server for Linux/ARM
Hi, I am trying to cross compile XFree86's 4.20 source tree on RedHat 7.2 for Linux 2.4.9-ac10-rmk2-np1-ads3 on a StrongARM-1110 processor. After playing a bit with the .cf & host.def files ... keyboard is working fine but touch screen is creating problems (Xfbdev gives a Segmentation Fault, but touch screen is working fine otherwise). Also, in my xc/programs/Xservers directory, I only see Xfbdev . why not TinyX or Xipaq or any other binary when I have specified them in the host.def file ? I am follwing instructions as given at this site : http://www.handhelds.org/minihowto/building-x.html This is what my host.def file looks like: #define KDriveXServer YES #define KdriveServerExtraDefines -DITSY -DMAXSCREENS=2 #define TinyXServerYES #define CrossCompiling YES #define TouchScreenYES #define ItsyCompilerBugYES #undef BuildRandR #define BuildRandR YES #define BuildXInputLib YES #define ProjectRoot/usr/X11R6 #define Freetype2Dir $(TOP)/extras/freetype2 #define Freetype2LibDir$(TOP)/exports/lib #define BuildXTrueType YES #define BuildScreenSaverExtYES #define BuildScreenSaverLibraryYES #define SharedLibXss YES #define ServerXdmcpDefines #define XfbdevServer YES #define XipaqServerYES #define BuildServersOnlyYES Is there anyway i can use -query sessionhost or -broadcast or -indirect options with Xfbdev ? I want X server to communicate with a remote host such that the clients are running on a remote host, and are using remote X to display their output on my local X terminal ( Xfbdev server running on LinuxARM). Plus, while compiling xc/programs/Xserver/hw/kdrive/itsy it gives error that there are no linux/itsy_fb.h or itsy_ts.h or itsy_buttons.h files ... I checked the source tree .. these files are not there too. I am using X 4.20 tarball . am I lacking something somewhere ? I really appreciate your help Sharad. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]HW interrupts for retrace sync
Dr. Aitchison Thank you for the advice and information. I will contact the Xfree86 board of directors. Daniel Quoting Dr Andrew C Aitchison <[EMAIL PROTECTED]>: > On Wed, 17 Jul 2002, Daniel Sheltraw wrote: > > > Hello Xpert list > > > > I am pleading with this list to help me obtain datasheets for > popular > > graphics cards. Or possibly select info from datasheets. I need > to > > use vertical-retrace-generated HW interrupts for synchronization > > of writes to VRAM. I have an ATI Radeon datasheet which has enabled > > > me to do this for ATI Radeon cards but thats all. I need to > support > > additional popular cards (with DVI output) and therefore need the > > > same info (the memory-mapped IO registers pertain to HW interrupts > > > from retrace events) for other popular cards. Can anyone please > help > > me? > > XFree86 have a substantial, but incomplete, collection. > However many of these documents were given to XFree86 under > agreements > which restrict how they may be used (XFree86 are prepared, in > principle, > to sign non-disclosure agreements, although clearly they must allow > the > distribution of source code generated from information in those > documents). > I believe that the XFree86 board of directors ([EMAIL PROTECTED] > IIRC) > control access to these documents. > > While I have no idea whether they could give you access, they, and > other > people with access to datasheets obtained under similar conditions, > may find it helpful if you can describe the project you are working > on, > and how it will be released. > > -- > 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 > ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]What happened to xc/lib/GL/mesa/dri ?
I just downloaded the latest CVS and noticed xc/lib/GL/mesa/dri is empty. Any reason for this? Johannes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Xlib extension missing...
Hi! I am using xawtv to view my quickcam webcamera and at startup it says this: This is xawtv-3.74, running on Linux/i586 (2.4.18) Xlib:extension "XVideo" missing on display ":0.0". ... Any ideas of what XVideo is and does? Is it important to view video images? Thanks in advance. Carlos ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XF86_SVGA server
David Bateman writes: > According to Carlos Luna <[EMAIL PROTECTED]> (on 07/16/02): > > Howdy folks! > > > > I've installed RedHat 7.2 (Linux 2.4.7) onto a PC-104 embedded board. > > It has a Chips&Technologies CT69000 graphics controller on board. > > Installed is GNome. > > When I start it up, Gnome has problems and I end up it text mode. > > The problems report a fatal server error: Signal 11 > > Without the log of the output from the Xserver this information is not > that useful. > I believe this still is the problem we had with the 4.1.0 driver. The fix would be to upgrade to 4.2. Unfortunately plain 4.2. has the problem that silken mouse cannot be disabled. Therefore one may have to disable the HW Cursor for all C&Ts on 4.2. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Trident Cyber9385: display trashed after resume from suspend
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 Regards, 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]Re: ATI Radeon 8500 support
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
Re: [Xpert]XServer start, cyrix, Geode driver
Nat Ersoz wrote: >Hi, > >I'm debugging an X driver for the Geode hardware. > >1. I've downloaded the latest "durango" code from National. It doesn't >seem to work worth a damn (I get stuck hanging on several "loop while >bit changes state" type code). Interestingly, none of these bits are >documented in the SC1200 register spec, which is 300 pages long :( ) > >Anyone have any positive thoughts regarding National's "Durango" XF86 >driver or helpful hints? Thanks! > >2. I thought that it would be useful to work from the Cyrix driver and >add the PCI probe code to it, and start from this much simpler and >cleaner code base. > >Well this approach sort of works, in that the PCI probe succeeds and I >get all the way up to CYRIXScreenInit(), which runs all the way through, >entry to exit (I can tell by putting in liberal doses of xf86Msg() >calls). At the end of CYRIXScreenInit(), I write a bunch of data to the >mapped frame buffer memory, just to see if anything faults out >(indicating a errored mapping) and everything proceeds OK - no faults. > >However, upon exiting CYRIXScreenInit(), the Server just sits there (see >attached log). Applications cannot connect to the display (they stall >without error, much like the server). > >Obviously, since the Cyrix driver is open source, I'll gladly >redistribute whatever useful progress I can make on this. > >Thanks, > > > > The only way I have been able to use a bit of Durango, is using the kernel Geode framebuffer driver, along with a standard/beautiful/well working Kdrive Xfbdev (framebuffer) server. The X driver was distributed for Xfree86 4.1.0, I don't know if changes with 4.2.x are significant enough to make it not working. Best Regards, Rolland Dudemaine ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Radeon Mobility M6 dri problem. Device busy
Hi guys, Dont worry about this mail, as the mediators had to check it out because > 40k. This probelme has already been delt with. thanks. On 2002.07.15 18:20 "Fisco ;)" wrote: > I have a stock redhat 7.3 install. and am trying to get DRI > working with the radeon mobility M6 card. > > I have attached the XF86 log and XF86Config files for those > of you who know how to fix this problem easily. > > Thanks, > Fisco. > > == > Get new ringtones and logos for your cellphone from Ananzi! > [http://www.exactmobile.com/ananzi/] > > > > > > # File generated by anaconda. > > Section "ServerLayout" > Identifier "Anaconda Configured" > Screen 0 "Screen0" 0 0 > InputDevice"Mouse0" "CorePointer" > InputDevice"Keyboard0" "CoreKeyboard" > EndSection > > Section "Files" > > # The location of the RGB database. Note, this is the name of the > # file minus the extension (like ".txt" or ".db"). There is normally > # no need to change the default. > > RgbPath "/usr/X11R6/lib/X11/rgb" > > # Multiple FontPath entries are allowed (they are concatenated > together) > # By default, Red Hat 6.0 and later now use a font server independent > of > # the X server to render fonts. > > FontPath "unix/:7100" > > EndSection > > Section "Module" > Load "GLcore" > Load "dbe" > Load "extmod" > Load "fbdevhw" > Load "dri" > Load "glx" > Load "record" > Load "freetype" > Load "type1" > EndSection > > Section "InputDevice" > Identifier "Keyboard0" > Driver "keyboard" > > # Option "AutoRepeat""500 5" > > # when using XQUEUE, comment out the above line, and uncomment the > # following line > # Option "Protocol" "Xqueue" > > # Specify which keyboard LEDs can be user-controlled (eg, with > xset(1)) > # Option "Xleds" "1 2 3" > > # To disable the XKEYBOARD extension, uncomment XkbDisable. > # Option "XkbDisable" > > # To customise the XKB settings to suit your keyboard, modify the > # lines below (which are the defaults). For example, for a non-U.S. > # keyboard, you will probably want to use: > # Option "XkbModel" "pc102" > # If you have a US Microsoft Natural keyboard, you can use: > # Option "XkbModel" "microsoft" > # > # Then to change the language, change the Layout setting. > # For example, a german layout can be obtained with: > # Option "XkbLayout" "de" > # or: > # Option "XkbLayout" "de" > # Option "XkbVariant""nodeadkeys" > # > # If you'd like to switch the positions of your capslock and > # control keys, use: > # Option "XkbOptions""ctrl:nocaps" > Option "XkbRules" "xfree86" > Option "XkbModel" "pc105" > Option "XkbLayout" "us" > #Option "XkbVariant""" > #Option "XkbOptions""" > EndSection > > Section "InputDevice" > Identifier "Mouse0" > Driver "mouse" > Option "Protocol" "PS/2" > Option "Device" "/dev/psaux" > Option "ZAxisMapping" "4 5" > Option "Emulate3Buttons" "no" > EndSection > > Section "Monitor" > Identifier "Monitor0" > VendorName "Monitor Vendor" > ModelName"Monitor Model" > HorizSync 31.5-48.5 > VertRefresh 50-70 > Option "dpms" > > # -- 1400x1050 -- > # 1400x1050 @ 60Hz, 65.8 kHz hsync > Modeline "1400x1050" 129 1400 1464 1656 1960 > 1050 1051 1054 1100 +HSync +VSync > > # 1400x1050 @ 70Hz, 76.8 kHz hsync > Modeline "1400x1050" 151 1400 1464 1656 1960 > 1050 1051 1054 1100 +HSync +VSync > > # 1400x1050 @ 75Hz, 82.3 kHz hsync > Modeline "1400x1050" 162 1400 1464 1656 1960 > 1050 1051 1054 1100 +HSync +VSync > > # 1400x1050 @ 85Hz, 93.2 kHz hsync > Modeline "1400x1050" 184 1400 1464 1656 1960 > 1050 1051 1054 1100 +HSync +VSync > > EndSection > > Section "Device" > # no known options > Identifier "ATI Radeon Mobility M6" > Driver "radeon" > VendorName "ATI Radeon Mobility M6" > BoardName "ATI Radeon Mobility M6" > > #BusID > EndSection > > Section "Screen" > Identifier "Screen0" > Device "ATI Radeon Mobility M6" > Monitor "Monitor0" > DefaultDepth16 > > Subsection "Display" > Depth 16 > Modes "1024x768" "800x600" "640x480" > EndSubsection > > EndSection > > Section "DRI" > Mode 0666 > EndSection > > > XFree86 Version 4.2.0 (Red Hat Linux release: 4.2.0-8) / X Window > System > (protocol Version 11, revision 0, vendor release 6600) > Release Date: 23 January 2002 > If the server is older t
[Xpert]Tiny Xserver frame-buffer
Hello. I am using tinyXserver to port to non-Linux system. In TinyXserver the Linux frame-buffer is used. In linux, mmap function is used to map the memory of framebuffer and this is done in hw/kdrive/fbdev/fedev.c. When write data to the screen, the data should be filled to the framebuffer. The system I am using now has a function for obtaining a framebuffer (array). We assign this instead of using mmap. We assume (after setting up data structures) that xserver should make updates to this framebuffer (array) we receive from our system. In our system there is a callback to sync timing with display and we just need to call one function to have the system update display based on contents of the framebuffer (send array data to display).. I understand our framebuffer data is supposed to be read and the data supposed to be displayed continuosly. My questions: 1. I cannot find which module (section of code/file) xserver uses to write data to the framebuffer after Pixblit routines. Where exactly does xserver write to framebuffer array? 2. If we execute TinyXserver only in Linux, a gray screen is shown. From observing behavior on Linux, when no client is running, we believe for our system a default gray screen should be filled to the framebuffer too. I don't know when this implemetation is done. Does anyone know where the greyscreen data is written to framebuffer? I appreciate any help with my questions. Thank you, M.N