Re: OpenGL + XvMC

[Benjamin Herrenschmidt]

> It *may* not always be required.  There have been GLX extensions in the 
> past (see my first message in this thread) that worked that way. 
> However, as we discussed earlier, this doesn't seem to work so well with 
> MPEG video files.  The main problem being that you don't get the frames 
> exactly in order.  You're stuck doing a copy either way.

Why ? You have usually enough video/AGP/whatever texture memory to
store multiple frames. I haven't looked at XvMc, but there is a
difference between rendering frames and scheduling them for display,
you render them to multiple buffers and schedule display when your
next expected display frame is ready.

I completely agree that it's a big waste to still have a copy in
cases where the HW let you avoid it

Ben.

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

Re: Radeon 9000 If (RV250), Mac G4 (Wintunnel) problems withXFree86

[Benjamin Herrenschmidt]

On Fri, 2003-05-30 at 11:52, Simon Urbanek wrote:
> Hi all,
> 
> I have several problems with the ATI Radeon drivers in XFree on my Mac G4 
> Windtunnel (dual 1.4GHz).

> Summary:
> 1) CRT + TMDS dual head configuration doesn't work
> 2) In all configurations colors are completely wrong
> 3) closing X blanks all monitors
> 
> I have tested following versions of XFree86:
> Debian sid "officail" 4.2.1
> Michel Daenzer's 4.2.1 DRI build
> Debian "inoffical" 4.3.0
> latest CVS build (by myself) as of yesterday (4.3.99...)

Ok, CVS is the really interesting one. Michel, did you ever commit
the fix of SURFACE_CNTL ? That should fix the colors at least on
the main aperture

> The first two worked even worse (no image at all), so in the following I'll 
> refer to the later two which produce exactly the same results.
> 
> .../...
>
> Probelm 2)
> No matter what combination (dual or single head) the colors are always wrong. 
> This is independent of the depth used (every time differently "wrong" colors 
> of course).

That is probably the SURFACE_CNTL problem.

> Problem 3)
> Shutting down X blanks both screens - i.e. the frame buffer is not correctly 
> restored. This is somewhat painful since after closing X you can access the 
> box via ssh only.

Typical with offb, X doesn't properly restore the radeon state to offb
graphics mode it seems.

> Other relevant info:
> kernel is 2.4.20-ben10 (the devel versions crash), frame buffer works only 
> with "video=ofonly".

Can you tell me more about the "crash" ? The benh-devel rsync should
work just fine on this config with more radeonfb fixes. Framebuffer
should work too without video=ofonly. Can you try my latest devel
kernel and tell me ? If it boots but with no framebuffer, can you
try to capture the boot log to a file and send it to me.

(Please, let's continue the kernel related discussion separately and
offlist)

> The system is debian "sid" (up-to-date). The CVS version of XFree86 was 
> compiled using gcc 3.2 on the same machine.
> 
> I don't know who's working on the radeon driver, but any help would be 
> appreciated. I'd be delighted to help to track all this further down if 
> possible ...
> 
> Cheers,
> Simon
-- 
Benjamin Herrenschmidt <[EMAIL PROTECTED]>
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

reread XF86Config

[Robert Woerle]

Where does the opening /reading of the XF86config file happen ???

i need to get the functions to be called a secound time ( or in a 
certain if loop ) in  a input driver !!!

Cheers Rob
--
_
*Robert Woerle
Linux & Customer Support*
*PaceBlade Technology Europe SA*
phone:  +49 89 552 99935
fax:+49 89 552 99910
mobile: +49 179 474 45 27
email:  [EMAIL PROTECTED] 
web:http://www.paceblade.com
_


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

Re: [XJANITOR] [Q] : where to submit patches?

[Egbert Eich]

Egbert Eich writes:
 > Aidan Kehoe writes:
 >  >  Ar an 2ú lá de mí 6, scríobh Egbert Eich :
 >  > 
 >  >  > Also they seem to have difficulties to make attachments
 >  > 
 >  > NB; this is not a badly-designed-user-interface issue; bugzilla on
 >  > bugs.xfree86.org is _buggy_ with regard to creating patches. 
 >  > 
 > 
 > Maybe you have misunderstood me:
 > Bugzilla isn't there to create patches.
 > However one can create an attachment which contains a patch
 > and mark the mime type as a patch. This works as I have already
 > done that myself.
 > So please explain what is '_buggy_'.
 > 

And I forgot to add:
First people advocated that XFree86 has a bugzilla. 
Now we have one and people complain that it is broken.

Our expertise is developing X not running a bugzilla.

Where are the people with this expertise, the volunteers 
who step up and offer to help us to tweak it so it suits
our needs best?
Where is the community spirit? I definitely miss it here 
in this list.

Egbert.

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

Re: [XJANITOR] : bug fix in savage driver

[Egbert Eich]

David Dawes writes:
 > 
 > The submission process is to go to bugs.xfree86.org.  If people want
 > their submissions to be seen, that's where they should go.  That's the
 > clearest explanation of the submission system that I can come up with.
 > 
 > Submissions sent elsewhere may or may not be seen.
 > 

Do we use fixes@ and patches@ to accept submissions which the author
chooses not to be seen?
Why should anybody want his submissions not to be seen?

The only case I can think of that should remain confidential until
officially announced are security fixes. These however should be
dealt with differently anyway. 

As we've decided to use bugs.xfree86.org we should no longer accept
patches thru the old channels at all. This should be made clear in the
auto-reply answer - if not done so already.

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

RE: OpenGL + XvMC

[Mark Vojkovich]

On Mon, 2 Jun 2003, Sottek, Matthew J wrote:

> 
> Let me preface my comment with "I don't know a lot about OGL" so some
> further clarification may be needed.
> 
> I am assuming that pbuffers are basically buffers that can be used
> as textures by OGL. I would then assume that the OGL driver would
> have some mapping of pbuffer id to the texture memory it represents,
> maybe this memory is in video memory maybe it has been "swapped out"
> so-to-speak by some texture manager etc.

   A pbuffer is a GLXDrawable like a window is.  You can make
current on it and draw to it.  The intention of pbuffers is that
they're always in hardware.


> 
> So basically this copies data from an XvMC offscreen surface to an
> OGL offscreen surface to be used by OGL for normal rendering purposes.
> Seems easy enough... I expect anyone doing XvMC would use the drm
> for the direct access (or their own drm equivalent) which would also
> be the same drm used for OGL and therefore whatever texture management
> needs to be done should be possible without much of a problem.
> 
> My main problem with the concept is that it seems that a copy is not
> always required, and is costly at 24fps. For YUV packed surfaces at
> least, an XvMC surface could be directly used as a texture. Some way
> to associate an XvMC surface with a pbuffer without a copy seems
> like something that would have a large performance gain.

   Can you use those non-power-of-two mpeg surfaces as normal
textures without limitations?  I don't think most hardware can
do that, some possibly can't at all.

   I expect binding an XvMC surface as a texture isn't implementable
without limitations on most hardware.  It also requires that OpenGL do
all the work for this since XvMC doesn't have access to OpenGL's texture
namespace.  It would also require cooperation between OpenGL and XvMC 
that makes me nervous.  OpenGL would have to make sure that XvMC's
Surface didn't go away while it was using it as a texture.  An
explict copy from the XvMCSurface to a pbuffer solves these problems
with the cost of the extra copy, which at least for my hardware,
isn't a big issue.

> Also, what is the goal exactly? 

   I am interested in getting mpeg into textures for the purpose
of incorporating into 3D scenes and video editing/post production.


Mark.

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

Re: status of SiS 3d?

[Alex Deucher]

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

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

Alex


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

Re: status of SiS 3d?

[Ian Romanick]

Thomas Winischhofer wrote:
Alex Deucher wrote:

right now just the 300 series (300, 305?, 540, 630/S/ST, 730) have DRI
support.  the old series 6326, 620, 530 don't have DRI support, but but
there are docs available (on the dri website I think) to write a DRI
driver; there was also a utah-glx driver for the that series.  I think
the 6327 might have been the internal sis name for the 300 series,
although that's just a guess on my part.  The 6326 and the 300 series
might be simialr enough to support them both with one driver, but I
No, they are not.
So...the 6327 is the 300 series, and it is not similar at all to the 
6326?  It's also not at all similar to the 315 series?  Wow.  Their 
hardware designers really went out of their way to make a driver 
writer's life miserable. :(

about the DRI, and I'd be willing to try to help you if you wanted to. 
I'll even provide cards.  sis 300 series cards are also very cheap. 
I wouldn't buy a 300 series card nowadays, as cheap as they might be. 
They are quite slow and far behind today's standards. Their only strong 
side is video support.
I certainly wouldn't buy one to replace my Radeon 8500! :)  It would be 
exclusively to update the drive.  It's the same reason I would be a 
Gamma card w/an R2 rasterizer...too bad there are *none* on eBay.  After 
I realized that, I pretty much give up any hopes of the gamma driver 
ever being updated.  That is, unless 3dlabs were to give out 
documentation for an R3 or R4 rasterizer.

It's doubtful however since sis refuses to hand out docs any more.
Once they are through with what is going on right now (can't tell you), 
the situation might become better.
We'll all be waiting with bated breath. :)

Thanks for your help.

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

Re: RFC: OpenGL + XvMC

[Ian Romanick]

Mark Vojkovich wrote:
On Mon, 2 Jun 2003, Ian Romanick wrote:

Instead of modifying your 3D driver, you've used an internal interface 
that, luckilly for you, just happened to already be there.  The rest of 
us may not be so lucky.
   I'd expect you to be able to do the same think with the DRI.
Intel implements their XvMC driver using the DRI.
Oh I know that we will be able to do it.  We'll just have to make the 
necessary changes to the 3D driver... ;)

Given that, I have only three comments / requests for the function.

1. Please provide a way to specify the destination buffer (i.e., 
GL_FRONT, GL_BACK_RIGHT, etc.) of the copy.
It's taking an argument like glDrawBuffer does.  It uses
the GL enums.
Perfect.

2. Make explicit the coordinate conversion monkey business.
   Will do.
I think that will avoid having to answer a lot of questions later. :)

3. Is there a way for apps to determine if this function is available on 
their hardware?  Later this year when pbuffers become available in the 
open-source drivers, we probably won't (initially) have support for this 
function.  I fully expect that support will follow soon, but it won't be 
there initially.
   There was a flag in the proposal that indicated it.  That's
the way other XvMC limitations/features are indicated, such as
whether or not subpicture scaling is supported.
Okay, I missed that the first time.  Sorry.

   What I'd really like to hear is if the DRI folks think they'd
have implementation problems with this in the Intel driver or 
some hypothetical driver.
Since I'll probably end up implementing it (at least in some drivers), I 
don't forsee any problems.  Since both the 3D drivers and the XvMC 
drivers are client-side, it should be pretty easy.  As soon as I get 
done writing all the parts so that we can have pbuffers (and 
ARB_vertex_buffer_objects, and superbuffers), I should be able to treat 
the XvMC copy call just like a glDrawPixels that sources from another 
pbuffer of a superbuffer.

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

Re: OpenGL + XvMC

[Ian Romanick]

Sottek, Matthew J wrote:
Let me preface my comment with "I don't know a lot about OGL" so some
further clarification may be needed.
I am assuming that pbuffers are basically buffers that can be used
as textures by OGL. I would then assume that the OGL driver would
have some mapping of pbuffer id to the texture memory it represents,
maybe this memory is in video memory maybe it has been "swapped out"
so-to-speak by some texture manager etc.
A pbuffer is (basically) just an off-screen window.  You can do the same 
things to a pbuffer that you can do to a normal window.  This includes 
copying its contents to a texture.  There was a proposal to bring 
WGL_render_texture to GLX, but, in light of other developments, there 
wasn't much interest.  It *may* be resurrected at some point for 
completeness sake, but I wouldn't hold my breath.

So basically this copies data from an XvMC offscreen surface to an
OGL offscreen surface to be used by OGL for normal rendering purposes.
Seems easy enough... I expect anyone doing XvMC would use the drm
for the direct access (or their own drm equivalent) which would also
be the same drm used for OGL and therefore whatever texture management
needs to be done should be possible without much of a problem.
Well, except that, at least in the open-source DRI based drivers, the 
texture memory manager doesn't live in the DRM (anymore than malloc and 
free live in the kernel).

My main problem with the concept is that it seems that a copy is not
always required, and is costly at 24fps. For YUV packed surfaces at
least, an XvMC surface could be directly used as a texture. Some way
to associate an XvMC surface with a pbuffer without a copy seems
like something that would have a large performance gain.
It *may* not always be required.  There have been GLX extensions in the 
past (see my first message in this thread) that worked that way. 
However, as we discussed earlier, this doesn't seem to work so well with 
MPEG video files.  The main problem being that you don't get the frames 
exactly in order.  You're stuck doing a copy either way.

Also, what is the goal exactly? Are you trying to allow video to be
used as textures within a 3d rendered scene, or are your trying to
make it possible to do something like Xv, but using direct rendering
and 3d hardware?
If you are trying to do the latter, it seems far easier to just plug
your XvMC extension into the 3d engine rather than into the overlay. I think
you've done the equivalent with Xv already.
I think the goal is to be able to do both.  Although, the idea of using 
MPEG video files as animated textures in a game is pretty cool. :)

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

RE: OpenGL + XvMC

[Sottek, Matthew J]

Let me preface my comment with "I don't know a lot about OGL" so some
further clarification may be needed.

I am assuming that pbuffers are basically buffers that can be used
as textures by OGL. I would then assume that the OGL driver would
have some mapping of pbuffer id to the texture memory it represents,
maybe this memory is in video memory maybe it has been "swapped out"
so-to-speak by some texture manager etc.

So basically this copies data from an XvMC offscreen surface to an
OGL offscreen surface to be used by OGL for normal rendering purposes.
Seems easy enough... I expect anyone doing XvMC would use the drm
for the direct access (or their own drm equivalent) which would also
be the same drm used for OGL and therefore whatever texture management
needs to be done should be possible without much of a problem.

My main problem with the concept is that it seems that a copy is not
always required, and is costly at 24fps. For YUV packed surfaces at
least, an XvMC surface could be directly used as a texture. Some way
to associate an XvMC surface with a pbuffer without a copy seems
like something that would have a large performance gain.

Also, what is the goal exactly? Are you trying to allow video to be
used as textures within a 3d rendered scene, or are your trying to
make it possible to do something like Xv, but using direct rendering
and 3d hardware?

If you are trying to do the latter, it seems far easier to just plug
your XvMC extension into the 3d engine rather than into the overlay. I think
you've done the equivalent with Xv already.

-Matt


-Original Message-
From: Mark Vojkovich [mailto:[EMAIL PROTECTED] 
Sent: Friday, May 30, 2003 4:30 PM
To: [EMAIL PROTECTED]
Subject: RFC: OpenGL + XvMC


   I'd like to propose adding a XvMCCopySurfaceToGLXPbuffer function
to XvMC.  I have implemented this in NVIDIA's binary drivers and
am able to do full framerate HDTV video textures on the higher end
GeForce4 MX cards by using glCopyTexSubImage2D to copy the Pbuffer
contents into a texture.


Status
XvMCCopySurfaceToGLXPbuffer (
  Display *display,
  XvMCSurface *surface,
  XID pbuffer_id,
  short src_x,
  short src_y,
  unsigned short width,
  unsigned short height,
  short dst_x,
  short dst_y,
  int flags
);

   This function copies the rectangle specified by src_x, src_y, width,
  and height from the XvMCSurface denoted by "surface" to offset dst_x,
dst_y 
  within the pbuffer identified by its GLXPbuffer XID "pbuffer_id".
  Note that while the src_x, src_y are in XvMC's standard left-handed
  coordinate system and specify the upper left hand corner of the
  rectangle, dst_x and dst_y are in OpenGL's  right-handed coordinate 
  system and denote the lower left hand corner of the destination 
  rectangle in the pbuffer.

"Flags" may be XVMC_TOP_FIELD, XVMC_BOTTOM_FIELD or XVMC_FRAME_PICTURE.
  If flags is not XVMC_FRAME_PICTURE, the src_y and height are in field
  coordinates, not frame.  That is, the total copyable height is half
  the height of the XvMCSurface.  

XvMCCopySurfaceToGLXPbuffer does not return until the copy to the
  pbuffer has completed.  XvMCCopySurfaceToGLXPbuffer is pipelined
  with XvMCRenderSurface so no explicit synchronization between 
  XvMCRenderSurface and XvMCCopySurfaceToGLXPbuffer is needed.
  
The pbuffer must be of type GLX_RGBA, and the destination of the
  copy is the left front buffer of the pbuffer.  Success is returned
  if no error occured, the error code is returned otherwise.

Possible Errors:

   XvMCBadSurface - The surface is invalid.

   BadDrawable - The pbuffer_id is not a valid pbuffer.

   BadMatch - The pbuffer is not of type GLX_RGBA or the
  pbuffer does not have a front left buffer.

  XvMCCopySurfaceToGLXPbuffer is supported if the following flag:

#define XVMC_COPY_TO_PBUFFER 0x0010

  is set in the XvMCSurfaceInfo's flags field.

  I'd like to bump the API version up to 1.1 and add this.  
Comments?


Mark.

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

Turning off key repeats from the server? [WAS: Re: Repeating Keystrokesin X]

[Harold L Hunt II]

Mark Vojkovich wrote:

   This is a kernel problem.  /dev/console is returning duplicate
key releases and XFree86 doesn't filter it out and sends duplicate
key release events to the clients.  I'm told it's fixed in some
newer kernels.   It seems to be specific to the Toshiba notebooks.
			Mark.
I am interested by this key repeating problem because Cygwin/XFree86 has 
had, for a long time now, a problem where one call to mieqEnqueue 
results in two or more keys showing up on the screen.  We have recently 
determined that this is due to the keyboard repeat mechanisms in the 
common X Server code, but I can't seem to find a way to disable it from 
the X Server in a manner similar to the way that 'xset r off' can 
disable it from the X Client side.

Any ideas on how to essentially perform 'xset r off' without a client 
connection?  I have searched and searched for a method to do this to no 
avail.

Thanks in advance for any pointers,

Harold

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

Re: RFC: OpenGL + XvMC

[Mark Vojkovich]

On Mon, 2 Jun 2003, Ian Romanick wrote:

> >I haven't touched the GL driver at all.  XvMC is direct rendered
> > and the assumption is that it's using the same direct rendering
> > architecture as OpenGL and should be able to get access to the
> > pbuffer memory if it can name it, just like GL would be able to
> > do.
> 
> You may not have touched the GL driver at all, but you are using some 
> sort of non-public interface to it to convert a pbuffer ID to an 
> address.  That was somewhat the point of Jon's comment.  I certainly 
> don't see anything in any pbuffer documentation that I've ever seen that 
> describes how to get the address in video memory of a pbuffer.  In fact, 
> the documentation that I have seen goes to some length to explain that 
> at certain points in time the pbuffer may not have an address in video 
> memory.
> 
> Instead of modifying your 3D driver, you've used an internal interface 
> that, luckilly for you, just happened to already be there.  The rest of 
> us may not be so lucky.

   I'd expect you to be able to do the same think with the DRI.
Intel implements their XvMC driver using the DRI.
   
> 
> Given that, I have only three comments / requests for the function.
> 
> 1. Please provide a way to specify the destination buffer (i.e., 
> GL_FRONT, GL_BACK_RIGHT, etc.) of the copy.

It's taking an argument like glDrawBuffer does.  It uses
the GL enums.

> 
> 2. Make explicit the coordinate conversion monkey business.

   Will do.

> 
> 3. Is there a way for apps to determine if this function is available on 
> their hardware?  Later this year when pbuffers become available in the 
> open-source drivers, we probably won't (initially) have support for this 
> function.  I fully expect that support will follow soon, but it won't be 
> there initially.

   There was a flag in the proposal that indicated it.  That's
the way other XvMC limitations/features are indicated, such as
whether or not subpicture scaling is supported.

   What I'd really like to hear is if the DRI folks think they'd
have implementation problems with this in the Intel driver or 
some hypothetical driver.


Mark.

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

Re: RFC: OpenGL + XvMC

[Ian Romanick]

Mark Vojkovich wrote:
On Sun, 1 Jun 2003, Jon Leech wrote:

On Mon, Jun 02, 2003 at 01:09:59AM -0400, Mark Vojkovich wrote:

  Extending GL to recognize a relatively unknown XFree86 format
is a hard sell.  I wouldn't even be able to convince my own company
to dirty their code for it seeing as how relatively nobody is using
XvMC.
   Do you implement this without touching the GL driver code? Seems
difficult to avoid touching the driver in the general case, when the
format and location of pbuffer memory is intentionally opaque.
   I haven't touched the GL driver at all.  XvMC is direct rendered
and the assumption is that it's using the same direct rendering
architecture as OpenGL and should be able to get access to the
pbuffer memory if it can name it, just like GL would be able to
do.
You may not have touched the GL driver at all, but you are using some 
sort of non-public interface to it to convert a pbuffer ID to an 
address.  That was somewhat the point of Jon's comment.  I certainly 
don't see anything in any pbuffer documentation that I've ever seen that 
describes how to get the address in video memory of a pbuffer.  In fact, 
the documentation that I have seen goes to some length to explain that 
at certain points in time the pbuffer may not have an address in video 
memory.

Instead of modifying your 3D driver, you've used an internal interface 
that, luckilly for you, just happened to already be there.  The rest of 
us may not be so lucky.

Given that, I have only three comments / requests for the function.

1. Please provide a way to specify the destination buffer (i.e., 
GL_FRONT, GL_BACK_RIGHT, etc.) of the copy.

2. Make explicit the coordinate conversion monkey business.

3. Is there a way for apps to determine if this function is available on 
their hardware?  Later this year when pbuffers become available in the 
open-source drivers, we probably won't (initially) have support for this 
function.  I fully expect that support will follow soon, but it won't be 
there initially.

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

Re: Repeating Keystrokes in X

[Mark Vojkovich]

   This is a kernel problem.  /dev/console is returning duplicate
key releases and XFree86 doesn't filter it out and sends duplicate
key release events to the clients.  I'm told it's fixed in some
newer kernels.   It seems to be specific to the Toshiba notebooks.

Mark.

On Mon, 2 Jun 2003, Mark Cuss wrote:

> Hello
> 
> I'm not sure if this is an X problem or not - if not, please let me know...
> 
> I have a Toshiba Satellite 2450 notebook on which I've recently installed RedHat 8.  
> Everything works OK, except that sometimes in X when I type (in a terminal or 
> anywhere else), my keystrokes are doubled up (ie - pressing "s" once results in 2 of 
> them in the terminal).  This can happen every 10th keystroke or so...
> 
> This doesn't seem to happen when X isn't running, so I think it may be an X thing.  
> I've attached my config file - I couldn't find anything out of the ordinary in 
> here...
> 
> If anyone has any suggestions I'd appreciate them...
> 
> Thanks
> 
> Mark
> 
> Mark Cuss, B. Sc.
> Real Time Systems Analyst
> CDL Systems Ltd
> Suite 230
> 3553 - 31 Street NW
> Calgary, AB, Canada
> 
> Phone: 403 289 1733 ext 226
> Fax: 403 282 1238
> www.cdlsystems.com

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

Re: RFC: OpenGL + XvMC

[Mark Vojkovich]

On Mon, 2 Jun 2003, Ian Romanick wrote:

> Mark Vojkovich wrote:
> > On Sun, 1 Jun 2003, Jon Leech wrote:
> >>You might want to think about how this could carry over to the
> >>upcoming super buffers extension, too, since that will probably replace
> >>pbuffers for most purposes within a few years. Since super buffers
> > 
> >   There are alot of people who are just discovering pbuffers now.
> > I would guess it would take years before superbuffers were widely used.
> 
> I would re-think that assumption. :)  A *lot* of people have known about 
> pbuffers but have intentionally avoided them.  When superbuffers are 
> available, they are going to jump all over it! 

   I'll believe it when I see it.


Mark.

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

Re: RFC: OpenGL + XvMC

[Mark Vojkovich]

On Sun, 1 Jun 2003, Jon Leech wrote:

> On Mon, Jun 02, 2003 at 01:09:59AM -0400, Mark Vojkovich wrote:
> >Extending GL to recognize a relatively unknown XFree86 format
> > is a hard sell.  I wouldn't even be able to convince my own company
> > to dirty their code for it seeing as how relatively nobody is using
> > XvMC.
> 
> Do you implement this without touching the GL driver code? Seems
> difficult to avoid touching the driver in the general case, when the
> format and location of pbuffer memory is intentionally opaque.

   I haven't touched the GL driver at all.  XvMC is direct rendered
and the assumption is that it's using the same direct rendering
architecture as OpenGL and should be able to get access to the
pbuffer memory if it can name it, just like GL would be able to
do.


Mark.

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

Re: Repeating Keystrokes in X

[Zan Lynx]

On Mon, 2003-06-02 at 16:30, Mark Cuss wrote:
> Hello
>  
> I'm not sure if this is an X problem or not - if not, please let me
> know...
>  
> I have a Toshiba Satellite 2450 notebook on which I've recently
> installed RedHat 8.  Everything works OK, except that sometimes in X
> when I type (in a terminal or anywhere else), my keystrokes are
> doubled up (ie - pressing "s" once results in 2 of them in the
> terminal).  This can happen every 10th keystroke or so...
>  
> This doesn't seem to happen when X isn't running, so I think it may be
> an X thing.  I've attached my config file - I couldn't find anything
> out of the ordinary in here...
>  
> If anyone has any suggestions I'd appreciate them...

I had a similar problem with the Gentoo 2.4.20 Linux kernels on a dual
Athlon MP.  It was a kernel timekeeping problem.  The kernel functions
that returned the time would report times that jumped around.  I believe
that when the time jumped forward a second or two, X decided that it
should have been doing keyboard repeat during the mysterious missing
seconds.

If I remember correctly, it was a TSC related problem.

Google found another possible solution, here:
http://www.calpoly.edu/~rmartine/configure.html#Keyboard
-- 
Zan Lynx <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part

Re: Repeating Keystrokes in X

[Harold L Hunt II]

Mark,

Have you tried running 'xset r off'?

Harold

Mark Cuss wrote:

Hello
 
I'm not sure if this is an X problem or not - if not, please let me know...
 
I have a Toshiba Satellite 2450 notebook on which I've recently 
installed RedHat 8.  Everything works OK, except that sometimes in X 
when I type (in a terminal or anywhere else), my keystrokes are doubled 
up (ie - pressing "s" once results in 2 of them in the terminal).  This 
can happen every 10th keystroke or so...
 
This doesn't seem to happen when X isn't running, so I think it may be 
an X thing.  I've attached my config file - I couldn't find anything out 
of the ordinary in here...
 
If anyone has any suggestions I'd appreciate them...
 
Thanks
 
Mark
 
Mark Cuss, B. Sc.
Real Time Systems Analyst
CDL Systems Ltd
Suite 230
3553 - 31 Street NW
Calgary, AB, Canada
 
Phone: 403 289 1733 ext 226
Fax: 403 282 1238
www.cdlsystems.com 




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

Re: Repeating Keystrokes in X

[Alan Hourihane]

On Mon, Jun 02, 2003 at 04:30:11PM -0600, Mark Cuss wrote:
> Hello
> 
> I'm not sure if this is an X problem or not - if not, please let me know...
> 
> I have a Toshiba Satellite 2450 notebook on which I've recently installed RedHat 8.  
> Everything works OK, except that sometimes in X when I type (in a terminal or 
> anywhere else), my keystrokes are doubled up (ie - pressing "s" once results in 2 of 
> them in the terminal).  This can happen every 10th keystroke or so...
> 
> This doesn't seem to happen when X isn't running, so I think it may be an X thing.  
> I've attached my config file - I couldn't find anything out of the ordinary in 
> here...
> 
> If anyone has any suggestions I'd appreciate them...

Try disabling xkb when starting X. So do this

startx -- -kb

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

Re: status of SiS 3d?

[Thomas Winischhofer]

Alex Deucher wrote:
right now just the 300 series (300, 305?, 540, 630/S/ST, 730) have DRI
support.  the old series 6326, 620, 530 don't have DRI support, but but
there are docs available (on the dri website I think) to write a DRI
driver; there was also a utah-glx driver for the that series.  I think
the 6327 might have been the internal sis name for the 300 series,
although that's just a guess on my part.  The 6326 and the 300 series
might be simialr enough to support them both with one driver, but I
No, they are not.

don't know.  Thomas Winischhofer would probably be a better person to
ask.  I was thinking of tackling this myself to try and learn more
Erm, no. I know nothing about DRI. Please don't encourage people to ask 
me about it :)

about the DRI, and I'd be willing to try to help you if you wanted to. 
I'll even provide cards.  sis 300 series cards are also very cheap. 
I wouldn't buy a 300 series card nowadays, as cheap as they might be. 
They are quite slow and far behind today's standards. Their only strong 
side is video support.

What I'd like to know is how different the 3D engine is on the 315
series is from the 300 series, and whether that could be supported at
some point.  
It's totally different; both register layout and other internals have 
changed - not even speaking of the Xabre 3D core (which is totally 
different to the 315's again)

> It's doubtful however since sis refuses to hand out docs
any more.
Once they are through with what is going on right now (can't tell you), 
the situation might become better.

Thomas

--
Thomas Winischhofer
Vienna/Austria
mailto:[EMAIL PROTECTED]  *** http://www.winischhofer.net
mailto:[EMAIL PROTECTED]
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Repeating Keystrokes in X

[Mark Cuss]

Hello
 
I'm not sure if this is an X problem or not - if 
not, please let me know...
 
I have a Toshiba Satellite 2450 notebook on which 
I've recently installed RedHat 8.  Everything works OK, except that 
sometimes in X when I type (in a terminal or anywhere else), my keystrokes are 
doubled up (ie - pressing "s" once results in 2 of them in the terminal).  
This can happen every 10th keystroke or so...
 
This doesn't seem to happen when X isn't running, 
so I think it may be an X thing.  I've attached my config file - I 
couldn't find anything out of the ordinary in here...
 
If anyone has any suggestions I'd appreciate 
them...
 
Thanks
 
Mark
 
Mark Cuss, B. Sc.Real Time Systems 
AnalystCDL Systems LtdSuite 2303553 - 31 Street NWCalgary, AB, 
Canada
 
Phone: 403 289 1733 ext 226Fax: 403 282 
1238www.cdlsystems.com


XF86Config.toshiba
Description: Binary data

Re: status of SiS 3d?

[Alex Deucher]

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

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

Alex

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


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

Re: status of SiS 3d?

[Ian Romanick]

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

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

Re: [XJANITOR] : bug fix in savage driver

[David Dawes]

On Mon, Jun 02, 2003 at 04:29:04PM +0200, Egbert Eich wrote:
>David Dawes writes:
> > On Sat, May 17, 2003 at 03:49:46PM -0600, Marc Aurele La France wrote:
> > >On Thu, 15 May 2003, Mike A. Harris wrote:
> > >
> > >> The [EMAIL PROTECTED] mail address still works?
> > >
> > >Yes.
> > 
> > It works in the sense that email sent to it is accepted and doesn't
> > bounce.  It is however a deprecated submission mechanism, and the
> > auto-reply message directs the sender to bugs.xfree86.org.
> > 
>David, 
>
>maybe you should have a clearification of the patch and fix
>submission system. I've seen people who were previously subscribed

The submission process is to go to bugs.xfree86.org.  If people want
their submissions to be seen, that's where they should go.  That's the
clearest explanation of the submission system that I can come up with.

Submissions sent elsewhere may or may not be seen.

David
-- 
David Dawes
Founder/committer/developer The XFree86 Project
www.XFree86.org/~dawes
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: RFC: OpenGL + XvMC

[Ian Romanick]

Mark Vojkovich wrote:
On Sat, 31 May 2003, Ian Romanick wrote:

Mark Vojkovich wrote:

On Fri, 30 May 2003, Ian Romanick wrote:

Mark Vojkovich wrote:

 I'd like to propose adding a XvMCCopySurfaceToGLXPbuffer function
to XvMC.  I have implemented this in NVIDIA's binary drivers and
am able to do full framerate HDTV video textures on the higher end
GeForce4 MX cards by using glCopyTexSubImage2D to copy the Pbuffer
contents into a texture.
This shoulds like a good candidate for a GLX extension.  I've been 
wondering when someone would suggest somthing like this. :)  Although, I 
did expect it to come from someone doing video capture work first.
  I wanted to avoid something from the GLX side.  Introducing the
concept of an XFree86 video extension buffer to GLX seemed like a hard
sell.  Introducting a well establish GLX drawable type to XvMC 
seemed more reasonable.
Right.  I thought about this a bit more last night.  A better approach 
might be to expose this functionality as an XFree86 extension, then 
create a GLX extension on top of it.  I was thinking of an extension 
where you would bind a "magic" buffer to a pbuffer, then take a snapshot 
from the input buffer to the pbuffer.  Doing that we could create 
layered extensions for binding v4l streams to pbuffers.  This would be 
like creating a subclass in C++ and just over-riding the virtual 
CaptureImage method.  I think that would be much nicer for application code.


   This isn't capture.  It's decode.  XvMC is a video acceleration
architecture not a capture architecture.  Even with capture, HW capture
buffer formats don't always line up nicely with pbuffer or texture formats.
I understand that it's not capture.  However, it's conceptually similar. 
 You have some opaque source that's generating frames of video.  You 
take whatever is the current frame and slurp it over to your pbuffer.  I 
doen't really matter if the video source is a file on your hard drive, a 
webcam on your PC, or a Dept. of Transportation traffic camera over the web.

That's why I'm saying that this new XvMC functionality could be used at 
the basis of a more general GLX extension.  I think a more abstract GLX 
extension is going to be far more useful to application developers. 
However, without something like XvMCCopySurfaceToGLXPbuffer in each 
thing that we want to use as a video source, the GLX extension can't be 
implemented.

The fact that buffer formats don't match is why I propsed having a 
CaptureImage (or something) function in the GLX extension.  That's the 
explicit copy of the next frame (either from the MPEG file or from the 
video camera) to the pbuffer.  It's just a name that would redirect to 
XvMCCopySurfaceToGLXPbuffer in this case.  The reason for the "bind" 
call is so that CaptureImage (which could probably use a better name, 
but it was late when I thought of it) knows what the video source is and 
what type of source (i.e., XvMC, v4l, etc.) it is.  That way it knows 
how to do the copy.  Then the application developer doesn't have to 
bother with that in their code.  That way if they want to switch from a 
video file to live video, they just make a different bind call, their 
code path doesn't have to change.

The really cool thing is that if all the real work (i.e., copying the 
data) is done in the XFree86 extensions, then all of the code for the 
GLX extension is *completely* device independent.  That ends up being a 
*HUGE* win.

hardware couldn't do mipmapping or GL_WRAP on non-power-of-two textures. 
 For the most part, without NV_texture_rectangle, you can't even use 
npot textures. :(
   And NV_texture_rectangle are still second class compared to normal
textures.  No video formats are powers of two, unfortunately.
Fair enough.  But that should change soon. :)

Status
XvMCCopySurfaceToGLXPbuffer (
Display *display,
XvMCSurface *surface,
XID pbuffer_id,
short src_x,
short src_y,
unsigned short width,
unsigned short height,
short dst_x,
short dst_y,
int flags
);
One quick comment.  Don't use 'short', use 'int'.  On every existing and 
future platform that we're likely to care about the shorts will take up 
as much space as an int on the stack anyway, and slower / larger / more 
instructions will need to be used to access them.
  This is an X-window extension.  It's limited to the signed 16 bit
coordinate system like the X-window system itself, all of Xlib and
the rest of XvMC.
So?  Just because the values are limited to 16-bit doesn't necessitate 
that they be stored in a memory location that's only 16-bits.  If X were 
being developed from scratch today, instead of calling everything short, 
it would likely be int_fast16_t.  On IA-32, PowerPC, Alpha, SPARC, and 
x86-64, this is int.  Maybe using the C99 types is the right answer anyway.


   XvMC is already using shorts.  No reason to be inconsistent now.
It reflects the underlying protocol limitations anyhow.  Something
to keep in mind for future extensions though.
True.  It should be pretty easy t

Xv scaling and Savage

[Juliusz Chroboczek]

On a Savage, Xv appears to do nearest-neighbour scaling (blocky
appearance).  Is that a limitation of the hardware or a limitation of
the driver?

Juliusz


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

Re: 1200dpi bitmap fonts in the tree

[Juliusz Chroboczek]

>> Is it me, or are we really shipping 1200dpi bitmap fonts as part of
>> XFree86?

AH> These have always been there. It's part of the Xprint server.

At the very same time when the tree contains both (1) a Type 1
rasteriser and (2) a Type 1 version of Courier.

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

Re: 1200dpi bitmap fonts in the tree

[Juliusz Chroboczek]

RM> The *.pmf files are no real fonts, they contain only the metrics for
RM> printer builtin fonts

That's not true.

  ftview 199 Courier.pmf

(Make sure you've got the 2.1.4 version of ftview.)

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

Re: RFC: OpenGL + XvMC

[Ian Romanick]

Mark Vojkovich wrote:
On Sun, 1 Jun 2003, Jon Leech wrote:
   You might want to think about how this could carry over to the
upcoming super buffers extension, too, since that will probably replace
pbuffers for most purposes within a few years. Since super buffers
  There are alot of people who are just discovering pbuffers now.
I would guess it would take years before superbuffers were widely used.
I would re-think that assumption. :)  A *lot* of people have known about 
pbuffers but have intentionally avoided them.  When superbuffers are 
available, they are going to jump all over it!  Not only that, on Linux 
on the Nvidia drivers and the ATI drivers for the FireGL 1/2/3 cards 
(not the Radeon based FireGL cards) support it at all currently.

Since nobody supports superbuffers yet, I think we could probably 
re-visit this issue when it is available.

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

Re: [XJANITOR] [Q] : where to submit patches?

[Egbert Eich]

Aidan Kehoe writes:
 >  Ar an 2ú lá de mí 6, scríobh Egbert Eich :
 > 
 >  > Also they seem to have difficulties to make attachments
 > 
 > NB; this is not a badly-designed-user-interface issue; bugzilla on
 > bugs.xfree86.org is _buggy_ with regard to creating patches. 
 > 

Maybe you have misunderstood me:
Bugzilla isn't there to create patches.
However one can create an attachment which contains a patch
and mark the mime type as a patch. This works as I have already
done that myself.
So please explain what is '_buggy_'.

Egbert.

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

Re: how to iterate through mode lists

[Alex Deucher]

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

Alex

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


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

Re: Having trouble getting CVS to compile

[Aidan Kehoe]

 Ar an 2ú lá de mí 6, scríobh Egbert Eich :

 > I wonder why this problem has not surfaced before. Is png.h installed
 > by default on all platforms we support.

Not on FreeBSD, NetBSD or OpenBSD I believe. People ended up working out
where to add PngLibDir and stuff, though.

 > I wonder how long we can keep up providing a self contained build 
 > environment.

Not too long, I suspect, which is good in some ways but bad in
others. Forcing XFree86 to distribute zlib when most platforms on which it
is used already have zlib is not a win. 

-- 
Parhásárd; rex quondam Pokémonorum, rex futuram Pokémonorum. 
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: how to iterate through mode lists

[Egbert Eich]

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

The mode list is a ring. Therefore tempmode->next will never be NULL.

Why don't you try this?

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

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

Re: MergedFB option for radeon driver

[Egbert Eich]

Thomas Winischhofer writes:
 > Alex Deucher wrote:
 > > I agree.  almost all of the MergedFB helper functions are generic. 
 > > However if we move to add generic interfaces for all of this we may
 > > want to think about re-structuring the XF86Config file so that all of
 > > these features do not have to be driver options, or maybe they are best
 > > as Driver options.  I dunno.
 > > 
 > > Another thing I was thinking about... I was looking at Thomas' sis and
 > > thinking about Xv attributes.  You can change visual settings of the
 > > overlay and even what head it displays on in the sis driver by
 > > adjusting the attributes.  So why not create Screen or entitiy
 > > attributes for the 2D driver.  that you allow change things on the fly
 > > instead of having to restart the X server.  You could make clone and
 > > mergedFB options, modes, framebuffer sizes, bit depth (although that
 > > might be an issue with some old toolkits), re-run DDC if you connect a
 > > new monitor, change OpenGL attributes, tv-out, etc.  Obviously this is
 > > something for 5.0.
 > > 
 > > Thoughts?
 > 
 > Egbert Eich was thinking in a similar way a few weeks back when we 
 > discussed this issue. We are planning to extend the misc extension with 
 > a property system like this.
 > 

My idea was to implement an extension where driver can advertise
properties that can be queried and (optionally) modified thru this 
extension.
I was planning to design the extension in a way that a GUI app can
get all information necessary to be able to offer config widgets
in a completely generic way. Also it is planned to have a property
registry so that GUI apps can offer a special configuration for
well known properties.
I was discussing this with Sven Luther on the very early days of
the forum list. I will go back and collect the ideas that were
discussed there and post them somewhere for further discussion.

I'm not sure when I will be able to work on this.

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

Re: [XJANITOR] [Q] : where to submit patches?

[Aidan Kehoe]

 Ar an 2ú lá de mí 6, scríobh Egbert Eich :

 > Also they seem to have difficulties to make attachments

NB; this is not a badly-designed-user-interface issue; bugzilla on
bugs.xfree86.org is _buggy_ with regard to creating patches. 

-- 
Parhásárd; rex quondam Pokémonorum, rex futuram Pokémonorum. 
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: Having trouble getting CVS to compile

[Egbert Eich]

Dr Andrew C Aitchison writes:
 > On 27 May 2003, Scott White wrote:
 > 
 > > Could anyone point me at some instructions to help me compile the
 > > XFree86 cvs, I'm having trouble.  I want to get access to the via driver
 > > recently added to the CVS so I can run X not in vesa mode on my Via
 > > Mini-itx based hush PC running Redhat 9.
 > 
 > > xcursorgen.c:35:17: png.h: No such file or directory
 > 
 > On a redhat 6.2 machine:
 > % locate png.h
 > /usr/include/png.h
 > % rpm -qf /usr/include/png.h
 > libpng-devel-1.0.14-0.6x.4
 > 

Hm, this is an external dependency which breaks self contained builds
of XFree86. We normally try to keep all lib sources that we depend on
(except libc, libm) in xc/extras/ to be independent of the installed
packages/versions on a system.
I wonder why this problem has not surfaced before. Is png.h installed
by default on all platforms we support.
I wonder how long we can keep up providing a slef contained build 
environment.

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

Re: [XJANITOR] [Q] : where to submit patches?

[Egbert Eich]

David Dawes writes:
 > On Sat, May 17, 2003 at 01:29:02PM +0200, Sven Luther wrote:
 > >On Sat, May 17, 2003 at 07:17:26AM -0400, Mike A. Harris wrote:
 > >> On Fri, 16 May 2003, Emmanuel wrote:
 > >> 
 > >> >so finally where it is the best to submit (rather) trivial patches ? 
 > >> >[EMAIL PROTECTED] works, but would it be better to use bugzilla instead?
 > >> 
 > >> Bugzilla is best.  That way other people in the community can
 > >> also see the patches and possibly use them.  If you send them to
 > >> [EMAIL PROTECTED] or [EMAIL PROTECTED] then most likely what
 > >> will happen is one of the following scenarios:
 > >> 
 > >> 1) You're redirected to submit your patches into bugzilla
 > >>in the future, but your patch is accepted by the *private* 
 > >>only mailing list, and may or may not be applied in the 
 > >>future whenever someone gets around to looking at it, if ever.
 > >
 > >Could the [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists not
 > >be automatically forwarded to bugzilla patches ?
 > 
 > I asked that a while ago, but nobody seems to know if/how bugzilla can
 > get input via email.
 > 

Processing and redirecting emails to fixes@ and patches@ to bugzilla
would not really solve the problem at all. There has been no fixed format
for submission these lists: patches are submitted as diffs, as diffs
contained in tarballs as full sourcecode tarballs or even only as a 
description what to change in the source code. I'm sure there are
plenty more ways.
We will never be able to process this and submit it to bugzilla in
a sane way.
One argument for bugzilla  was that it would help to reduce the
workload of the the developers as the developer could communicate with
the patch submitter and ask him to make fixes to the patch himself.

However what we currently see is the contrary: It is not even possible
to easily extract fixes and patches from the bug submission.
Users seem to have a hard time to correctly set up the fields in
bugzilla. Also they seem to have difficulties to make attachments and
if they do they frequently set the file type wrong.
We may have to have a second instance of bugzilla just for patch and
fix submission which comes with different frontend with less degrees
of freedom and 'tags' the submission as a patch.
It should also contain instructions to submit patches only - no
tarballs and no complete source files and attach these patches - not
submit them in the discription.

During the bugzilla flamewar we had in January a lot of people
advocating it here talked about how much experience they had setting 
up a bugzilla. 
Now since we have this bugzilla these people are invited to help
our bugzilla maintainer to customize it to best suite our needs.


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

Re: SDK and drivers.

[Egbert Eich]

Sven Luther writes:
 > On Tue, Apr 22, 2003 at 11:58:03AM +0200, Egbert Eich wrote:
 > > Sven Luther writes:
 > >  > Hello, ...
 > >  > 
 > >  > I have been trying to build the driver SDK thingy on both 4.3.0 and
 > >  > head, and it seems to be somewhat broken. In particular there are some
 > >  > missing files, which altough needed, are not part of the SDK, like the
 > >  > render includes for example.
 > >  > 
 > >  > So, i looked at the whole stuff, and have been trying to fix this, but
 > >  > encountered that many driver missed declaring some of their file, which
 > >  > is a pain.
 > >  > 
 > >  > Since the driver SDK is aimed mostly at building drivers, maybe listing
 > >  > all files as being part of the SDK in the Imakefile is not the most
 > >  > appropriate way of doing this, since mostly _all_ the files of the
 > >  > driver directory are really needed, and in fact my aim is to not use the
 > >  > drivers from the sdk, but the ones from the driver module just announced
 > >  > by Alan.
 > > 
 > > I'm currently exploring a toatlly new SDK which takes advantage of
 > > driver modules. It doesn't even attempt to add drivers to the SDK,
 > > but it expects them to be dropped in from a separate tarball.
 > 
 > Hello, 
 > 
 > I expect to be looking at the SDK stuff again nextly, and would like to
 > know if you did advance some with this code since you wrote this ? 

No, unfortunately not. I've just returned from vacation and didn't
have time to look at it any more.
The next two weeks are pretty occupied with other things, too.

 > 
 > Also, would your new SDK still use a fixed path or should it be possible
 > to install it anywhere ?
 > 

Fixed path? I have not looked at the old SDK, but my plan is to
have it like the build tree so you should be able to put it anywhere.

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

Re: [XJANITOR] : bug fix in savage driver

[Egbert Eich]

David Dawes writes:
 > On Sat, May 17, 2003 at 03:49:46PM -0600, Marc Aurele La France wrote:
 > >On Thu, 15 May 2003, Mike A. Harris wrote:
 > >
 > >> The [EMAIL PROTECTED] mail address still works?
 > >
 > >Yes.
 > 
 > It works in the sense that email sent to it is accepted and doesn't
 > bounce.  It is however a deprecated submission mechanism, and the
 > auto-reply message directs the sender to bugs.xfree86.org.
 > 
David, 

maybe you should have a clearification of the patch and fix
submission system. I've seen people who were previously subscribed
to the fixes and patches mailing lists that they are no longer
receiving any submissions.
You say the emails are still accepted. Does that mean that they
are still collected for inclusion into the tree?
If so we have to sort out which ones were also submitted to
bugzilla after the submitter has been directed to bugs.xfree86.org.

Egbert.

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