Sun CG6

[Michael]

Hello,

here's a slightly enhanced version of the suncg6 driver, it adds some basic 
acceleration:
- screen-to-screen copies
- solid rectangle drawing

I used XFree86 4.4 but as far as I can tell the driver didn't change for 4.5.
It works fine on my Ultra 1 under NetBSD/sparc64, -current kernel and userland.

have fun
Michael


suncg6.tar.bz2
Description: Binary data


pgpO2rcyzCzJ3.pgp
Description: PGP signature

Sun GX

[Michael]

Hello,

here's a slightly updated suncg6 driver:

(II) SUNCG6(0): Using XFree86 Acceleration Architecture (XAA)
Screen to screen bit blits
Solid filled rectangles
Indirect CPU to Screen color expansion
Solid Horizontal and Vertical Lines
Offscreen Pixmaps
Setting up tile and stipple cache:
9 128x10 slots
(II) /dev/fb0: Using acceleration

Works fine on my Ultra 1 under NetBSD/sparc64 -current with

cgsix0 at sbus0 slot 1 offset 0x0 vector 5 ipl 5: SUNW,501-2325, 1152 x 900, 
rev 11 (console)
cgsix0: attached to /dev/fb
wsdisplay0 at cgsix0 kbdmux 1: console (std, vt100 emulation)

have fun
Michael


suncg6.tar.bz2
Description: Binary data


pgp2oWaOQXNg4.pgp
Description: PGP signature

Re: Sun GX

[Michael]

Hello,

> > cgsix0 at sbus0 slot 1 offset 0x0 vector 5 ipl 5: SUNW,501-2325, 1152 x 
> > 900, rev 11 (console)
> > cgsix0: attached to /dev/fb
> > wsdisplay0 at cgsix0 kbdmux 1: console (std, vt100 emulation)
> 
> I have integrated this and committed the result.  Please base any further 
> work on the CVS version.

Cool :)

There will almost certainly be at least one more update, because...
- the driver doesn't recognise boards with more than 1MB VRAM yet, instead it 
always assumes 1MB or width*height, whatever is bigger. Maybe I should round up 
to the next megabyte boundary if I can't find a reliable way to find the 
correct size.
- stippled drawing isn't there yet
- line drawing is still unaccelerated.

have fun
Michael


pgpDCynzkZKha.pgp
Description: PGP signature

Keyboard handling on non-x86

[Michael]

Hello,

right now I'm struggling to get XFree86 properly supported on
NetBSD/sparc and sparc64 and one problematic point is the keyboard
handling. 
With
Option "Protocol" "wscons"
Option "Device" "/dev/wskbd0"
things work reasonably well but the Xserver doesn't pot these options
into XF86Config when configuring itself, so I tried to get the
read-input-from-console mode to work. This is where the mess started. 
XFree tries to switch the console fd into raw mode and if that fails it
complains and recommends to add the above lines to XF86Config. This was
ok since we didn't support raw mode on Sun keyboards. Now we do.
In this mode of operation XFree obviously expects to read AT-style
scancodes from the console fd and feed them into its event queue via
xf86PostKbdEvent(). With a Sun Type 5 this can't work since it uses a
completely different set of scancodes ( but at least it uses but 7 the
same way to signal key up / down ). What confused me for a while is some
code in xf86PostKbdEvent() that seemed to handle Sun scancodes but as it
is now it can't possibly work. And it doesn't properly translate Sun
scancodes into whatever X uses internally, so I conditionally replaced
xf86Info.kbdEvents with a function that reads from the console fd,
translates Sun scancodes unto AT scancodes the way xf86PostWSKbdEvent()
does and feeds them to xf86PostKbdEvent(). This works mostly, but I
found that the PageDown key didn't deliver a scancode. Some debugging
revealed something ugly - its translated keycode collides with the
prefix code used by AT keyboards for cursor keys and the number block
and the prefix handling in xf86PostKbdEvent() is skipped when
xf86Info.kbdEvents points to the wscons version. Still easy to get
around this, ugly as it is.
Finally I found that atKeynames.h defines names for Sun-typical keys
found nowhere else, but what it assigns them starts at 0x84 so it
collides with the AT keyup/down bit - to deliver it to
xf86PostKbdEvent() I'd have to prefix them which I can't since prefixing
is disabled. 

So - what would you suggest - I think I should replace
xf86PostKbdEvent() with something usable by wscons which doesn't need
all this AT-inherited nonsense, I don't really see why I should emulate
this broken excuse for a protocol to get keyboard events into the
Xserver. There are two sets of functions which seem to deal with
keyboard input on BSD - one in bsd_io.c and another in bsd_kbd.c - the
latter seems unused. What's the purpose of this?
And lastly - why does the wscons protocol option require a device name?
Defaulting it to /dev/wskbd should do the trick.
Would it be better to write an input driver module for wskbd that uses
wscons' hardware-independent scancodes instead? Seeing the mess that the
current code is I'd almost think so.

have fun
Michael


pgplAqECMLhX6.pgp
Description: PGP signature

Re: Keyboard handling on non-x86

[Michael]

Hello,

> Ideally it should automatically determine when "wscons" mode is
> needed.

Ok, on NetBSD that would be always, none of the pre-wscons ports runs
XFree as far as I can tell. So - some ( like x86 ) might not exactly
/need/ it but they /should/ use it.

> This would be easier to do via the modular XFree86 "keyboard" driver
> than with the built-in "kbd" driver.  See more below.

Yeah, I finally found it - looks MUCH more sane than what I've been
ranting about yesterday. In fact I got it to work pretty well now and I
have a few questions.

> I would suggest following this up via the modular "keyboard" driver.
> Like the mouse driver, it consists of two components: a
> platform-independent input driver module in xfree86/input/keyboard/,
> and an OS-specific portion in xfree86/os-support/platform/.  The
> interface between the two should make it possible to avoid forcing all
> keyboard models into the AT-style mould. 

That's what I'm doing now. When I find a Sun keyboard I simply change
the default xkb settings to rules=sun and model=type4 or type5. Works
pretty well when I disable scancode remapping ( it's still in the
driver... ) - then even the Sun-specific keys work and it can still be
overridden via XF86Config.

> Also, as with the mouse driver, it should be able to automatically
> determine which is the best device/protocol mode to use at run-time.

Agreed.

> If you find any issues with the keyboard driver or the interface
> between the platform-specific and platform-independent components of
> it, this is the place to discuss and resolve them.

What I'm doing right now is to make the keyboard driver use xkb for
scancode->keysym translation, at least for Sun keyboards. This allows
all keys to work and avoids all these AT-scancode quirks. To do that I
leave both the remap function and the scancode translation table at
NULL and set the XKB keymap according to what wskbd tells me about the
keyboard ( sun type4 or sun type 5 ). The wscons support code there has
numerous issues:
- it didn't know about WSKBD_TYPE_SUN5 so initially it tried to use
AT-style scancode translation.
- the mapping between XLEDs and wscons ioctls is wrong. The reason seems
to be the sun keymap which says:

indicator 4 = "Caps Lock";
indicator 3 = "Compose";
indicator 2 = "Scroll Lock";
indicator 1 = "Num Lock";

... while XFree's map says:

indicator 1 = "Caps Lock";
indicator 2 = "Num Lock";
indicator 3 = "Scroll Lock";

the latter seems to be hard-coded into the driver. 

The driver still attempts to translate everything into AT scancodes
which is a Bad Thing in my opinion, I think the main reason is to catch
special keystrokes like ctrl-alt-backspace before xkb does. Is this
really necessary? Shouldn't xkb handle them correctly?
Wouldn't it be better to select a sane xkb map instead of attempting to
make everything fit a PC keymap?

have fun
Michael


pgpdJfv9O8YRx.pgp
Description: PGP signature

Re: Keyboard handling on non-x86

[Michael]

Hello,

here's the patch.

> If older versions of NetBSD (x86 at least) don't have wscons, there
> should at least be a check that it is available.

Did that. X -configure with wscons support / NetBSD it will try to open
/dev/wskbd, if it succeeds it will write driver kbd, protocol wskbd and
device /dev/wskbd into XF86Config, if not it falls back to driver
keyboard.

> I suggested using the xfree86 XKB rules/keycodes for consistency of
> features across platforms and because they are the best-supported ones
> within XFree86.  In the past, diverging from this has resulted in
> unnecessary feature and functionality differences between platforms.
> Also, the set of XKB key tokens (the  objects mapped to raw
> keycodes by the keycodes files) would ideally be platform-independent
> to avoid the unnecessary need to have multiple copies of the XKB
> symbol mappings.

I added the Sun-specific keynames found in atKeynames.h to the Sun map
in bsd_KbdMap.c and changed both the legacy driver and the modular
keyboard driver to drop anything that's no sane scancode ( like
KEY_NOTUSED ) and in case of the legacy driver anything that translates
to something >0x7f because xf86PostKbdEvent() uses 0x80 as up/down
indicator. This way everything is fine and the extra keys are (almost)
all usable with kbd while the legacy driver behaves the same as before -
extra keys don't work, some scancodes get mangled ( like most cursor
keys ).

> The symbols mappings in xkbcomp/symbols/pc are the most full-featured
> that we have, and they're not really PC-specific.  In fact, it is
> probably a good time to promote them out of their pc/ subdirectory.

They don't contain mappings for Sun extra keys like audio up/down and
the extra function keys. Then there's nothing to do for the compose key.

> That would just leave the issue of whether the raw keyboard codes are
> mapped to a consistent set of X keycodes within the driver, or whether
> that is handled by using different XKB keycodes files.  I don't see a
> great advantage to doing this mapping at the XKB level.

The Sun map had a minor mistake (or feature?)- Props/L3 and ScrollLock
were swapped.

have fun
Michael


xfree_kbd.patch
Description: Binary data


pgpZ0VYEhiJev.pgp
Description: PGP signature

Re: Keyboard handling on non-x86

[Michael]

Hello,

> That's good.  Even better, especially for the modular driver, would be
> to handle this automatically in the driver at run-time.  The mouse
> driver does this and should handle auto-detection of wscons support on
> NetBSD for mouse input without the need for any mouse configuration
> data in the config file.

I'll have a look how the mouse driver does that and see if I can do
something similar for kbd - I'm not sure that's really necessary though,
the only NetBSD port that could run XFree86 without wscons was i386 - it
switched to wscons ages ago.

> >The Sun map had a minor mistake (or feature?)- Props/L3 and
> >ScrollLock were swapped.
> 
> Sounds like a bug.

I wasn't sure, I have only Type 5 keyboards here ( well, one 5 and one
5c, both US ). Anyway, I tested the whole thing on NetBSD/macppc too -
works as expected.

have fun
Michael


pgplSlTtH5Q5o.pgp
Description: PGP signature

sunffb

[Michael]

Hello,

just a question. Again. 
We finally got the sunffb driver to work on NetBSD/sparc64, including
acceleration. Turns out there was a problem in the VIS assembler code:
 wr %g0, 0, %fprs
this will turn off the FPU so any subsequent FPU instruction will cause
a trap. On NetBSD this led to huge numbers of traps which rendered the
Xserver unusable when acceleration was enabled.
So for NetBSD I changed this to
 wr %g0, 4, %fprs
to leave the FPU active and clean only the dirty bits. No more excessive
traps and things work.

Since I highly doubt this is an oversight - what's the purpose of
turning off the FPU after using VIS? Apparently the author expected the
OS to do something which NetBSD doesn't do, but what? And why? Provoking
a trap seems a rather expensive way to reset the FPU ( if that's the
purpose... )

have fun
Michael 

PS: yes, I mailed the author too


pgpvAjIeE586X.pgp
Description: PGP signature

Re: sunffb

[Michael]

Hello,

> > We finally got the sunffb driver to work on NetBSD/sparc64,
> > including acceleration. Turns out there was a problem in the VIS
> > assembler code:
> >  wr %g0, 0, %fprs
> > this will turn off the FPU so any subsequent FPU instruction will
> > cause a trap. On NetBSD this led to huge numbers of traps which
> > rendered the Xserver unusable when acceleration was enabled.
> > So for NetBSD I changed this to
> >  wr %g0, 4, %fprs
> > to leave the FPU active and clean only the dirty bits. No more
> > excessive traps and things work.
> 
> I'm inclined to simply change both occurrences.

At least for NetBSD we'll definitely do so in our repository.
 
> > Since I highly doubt this is an oversight - what's the purpose of
> > turning off the FPU after using VIS? Apparently the author expected
> > the OS to do something which NetBSD doesn't do, but what? And why?
> > Provoking a trap seems a rather expensive way to reset the FPU ( if
> > that's the purpose... )
> 
> > PS: yes, I mailed the author too
> 
> Let us know if you get a response.

He said it's supposed to keep the scheduler from storing/saving FPU
context until someone really uses it again ( which causes a trap ), at
least on Linux. I'm not sure this helps much in this code - the ffb/afb
doesn't have block transfer hardware ( they dropped it because VIS is
faster ) so the VIS code will run a lot.
Maybe writing 0 into %fprs should be Linux-specific.

have fun
Michael


pgpz7TGN24058.pgp
Description: PGP signature

Xrender and 64bit

[Michael]

Hello,

I recently found out that whoever wrote Xrender apparently didn't waste
a single thought on 64bit systems. Base types are unsigned longs ( see
X11/extensions/render.h ):

typedef unsigned long   Glyph;
typedef unsigned long   GlyphSet;
typedef unsigned long   Picture;
typedef unsigned long   PictFormat;

but everything seems to assume they're size 4 bytes and goes some
lengths to ensure 4 byte alignment but this still leads to occasional
SIGBUS from Xserver/render/render.c, especially
ProcRenderCompositeGlyph(). A quick, working but dead ugly 'fix' is
this: 

Index: render.c
=== 
RCS file: /cvsroot/xsrc/xfree/xc/programs/Xserver/render/render.c,v
retrieving revision 1.1.1.6 diff -u -w -r1.1.1.6 render.c 
--- render.c 18 Mar 2005 13:13:16 -  1.1.1.6 
+++ render.c24 Jul 2005 17:46:09 - 
@@ -1300,7 +1300,7 @@
{
if (buffer + sizeof (GlyphSet) < end)
{
-   gs = *(GlyphSet *) buffer;
+   gs = *(CARD32 *) buffer;
glyphSet = (GlyphSetPtr) SecurityLookupIDByType (client,
 gs,
 GlyphSetType, 

A real fix would be to change the base types to something that's always
32bit I think but that would disrupt more or less everything that uses
Xrender since they're exposed to clients.

Any ideas what to do about this? On sparc64 this leads to firefox
occasionally crashing the Xserver and I'm pretty sure it would affect
other 64bit architectures as well.

have fun
Michael


pgpRjsdNR20SZ.pgp
Description: PGP signature

Re: Xrender and 64bit

[Michael]

Hello,

> FYI, this is the same problem as: 
> <https://bugs.freedesktop.org/attachment.cgi?id=3095>

Indeed. Is this considered the 'canonical' fix by the Xrender guys?

have fun
Michael


pgplliAkBwzYQ.pgp
Description: PGP signature

ADB keyboards and kbd

[Michael]

Hello,

the attached patch fixes a problem with 'kbd' and ADB keyboards.
Apparently these keyboards send a 0 after each caps-lock, but since 0 is
used for 'a' we can't just drop it. This patch adds a remap function
which takes care of that - without it you'd get a spurious 'a' or 'A'
after each caps-lock.
Tested on NetBSD/macppc.

have fun
Michael


bsdadbkbd.patch
Description: Binary data


pgp3n5oCodEVO.pgp
Description: PGP signature

Re: WD90C24 Port

[Michael]

Hello,

> I've got an old laptop with a WD90C24 video chip. By default, X comes
> up in 320x200x1, which is not too useful. While I am a competent 
> programmer, I have not done device drivers for Linux.

As far as I remember that's a dumb framebuffer also known as ( or
closely related to ) PVGA1A and maxed out at 640x400x8 ( with a 256kB
board, I had one like that ages ago ) - no acceleration, 8 or 16bit ISA
interface, slowish. Should be fully VGA compatible though, so 640x480 in
16 colours should be possible with the generic driver.

have fun
Michael


pgp8qtYTMj2aj.pgp
Description: PGP signature

Re: tdfx and DDC2

[Michael]

Hello,

> >the attached patch adds DDC2/I2C support to the tdfx driver which has
> >the distinct advantage to work anywhere since it doesn't depend on
> >the vbe module. It will try DDC2 first and if that fails fall back to
> >the old vbe stuff when possible.
> >Moved mode validation and related stuff /after/ monitor detection.
> 
> That looks reasonable.
> 
> Does the vbe/int10 portion still need to be disabled for PowerPC?

I don't see why they should be enabled - they're PC-specific and even
with x86 emulation they would be pretty much useless since you're not
too likely to encounter a graphics board with PC firmware in a Mac ( or
other PowerPC boxes )

have fun
Michael


pgpkYFlZetwS6.pgp
Description: PGP signature

Re: tdfx and DDC2

[Michael]

Hello,

> >>> the attached patch adds DDC2/I2C support to the tdfx driver which
> >>> has the distinct advantage to work anywhere since it doesn't
> >>> depend on the vbe module. It will try DDC2 first and if that fails
> >>> fall back to the old vbe stuff when possible.
> >>> Moved mode validation and related stuff /after/ monitor detection.

> >> That looks reasonable.

> >> Does the vbe/int10 portion still need to be disabled for PowerPC?

> > I don't see why they should be enabled - they're PC-specific and
> > even with x86 emulation they would be pretty much useless since
> > you're not too likely to encounter a graphics board with PC firmware
> > in a Mac ( or other PowerPC boxes )
> 
> That's _no_ reason to disallow them.  After all even your Mac has PCI
> slots, not Mac-PCI slots, because the later don't exist.

But the chances that it will ever have a VESA BIOS or anything
responding to int10 in a PCish way is extremely small. I agree, it
shouldn't have to be #ifdef'ed out as it is, but these modules would be
useless on almost any PowerPC machine. 

have fun
Michael


pgpa2feAgQUXk.pgp
Description: PGP signature

Re: tdfx and DDC2

[Michael]

Hello,

> >I don't see why they should be enabled - they're PC-specific and even
> >with x86 emulation they would be pretty much useless since you're not
> >too likely to encounter a graphics board with PC firmware in a Mac (
> >or other PowerPC boxes )
> 
> Wrong.  No hardware manufacturer in their right mind would build a 
> Mac-only PCI graphics board, with the possible exception of Apple.  

What the hell are you talking about? VESA BIOS is x86 only. Int10 is PC
only. 

> They're going to build a generic graphics board that works in a PC and
> by the way also works in a Mac.  Such a board will have a video BIOS.

Wrong.
A Mac graphics board will have an OpenFirmware driver and possibly a
MacOS driver in ROM, not a VESA BIOS. 

have fun
Michael


pgpZpiGrOZFuS.pgp
Description: PGP signature


pgpnhE8ZdTJtU.pgp
Description: PGP signature

Re: tdfx and DDC2

[Michael]

Hello,

> Not entirely true.  What you say only matters for the primary head,
> and only because most manufacturers package only one image (x86, EFI,
> OpenFirmware,  etc) in their PCI ROMs.

True, but in this case - tdfx - irrelevant. The driver uses vbe only for
monitor ID as far as I can tell, so a voodoo3 as 2nd head should work
even without any firmware ;) 

have fun
Michael


pgpfHQbl7sZom.pgp
Description: PGP signature

Re: tdfx and DDC2

[Michael]

Hello,

> Is the implication here that plugging a PC PCI graphics card into
> a powerpc machine will never work (as a secondary display), even
> if the software driving it knows how to initialise it in the absence
> of OpenFirmware?

Of course not. All I said is that you're rather unlikely to find a
VESA BIOS on a graphics card in a non-PC-box. And in the case at hand  -
tdfx - we don't need firmware help to set up the hardware anyway.

have fun
Michael



pgp9EvtmLwwX6.pgp
Description: PGP signature

Re: tdfx and DDC2

[Michael]

Hello,

> Marc appears to have fixed various issues for int10/vbe on non-x86
> platforms as part of his sparc work.  Perhaps some of those same
> issues prevented this stuff from working on powerpc in the past and
> so these #ifdef's can be removed now.  int10/vbe should fail-safe
> on hardware that does not have an x86 BIOS, and if they don't it
> is a bug.

I'll just remove them and tell you what happens?

have fun
Michael


pgpIzRNwmIDi7.pgp
Description: PGP signature

Re: tdfx and DDC2

[Michael]

Hello,

> >> Marc appears to have fixed various issues for int10/vbe on non-x86
> >> platforms as part of his sparc work.  Perhaps some of those same
> >> issues prevented this stuff from working on powerpc in the past and
> >> so these #ifdef's can be removed now.  int10/vbe should fail-safe
> >> on hardware that does not have an x86 BIOS, and if they don't it
> >> is a bug.
> >
> >I'll just remove them and tell you what happens?
> 
> Sounds good.  If anyone has a powerpc with a PC card as a secondary
> to test with, that'd be good too.

Hrm, all my PCI graphics boards here have some sort of OpenFirmware (
not necessarily Apple ) but I guess I could flash a Millennium back to
PC-dom, the ROM images should still be on matrox.xom somewhere.

have fun
Michael


pgpV2nrhVsbqp.pgp
Description: PGP signature

Re: XFree with Voodoo 5

[Michael]

Hello,

> Hello I've that improvments have just been done for endianess on the
> last release of XFree.
>  
> I have a Pegasos 2 (PowerPC G4) and a Voodoo 5 gfx card with Knoppix
> version of Linux.
> Today I can't launch X server or to use MacOSX with good colors.
> see : http://www.mail-archive.com/devel@xfree86.org/msg06203.html
> which seems to be the same problem.

The mail you're linking to doesn't have anything to do with an
endianness problem, rather with XFree being unable to access PCI IO
space for some reason. I have no idea how Linux handles this, probably
not at all.
The tdfx driver itself is pretty unlikely to have an endianness problem.

> So I would like to know if the last version of XFree now corrects this
> problem ? (version 4.5.99.11 September 2005)

Well, what exactly /is/ your problem? What do you mean by 'good colors'?

have fun
Michael


pgpcj4b7Srauf.pgp
Description: PGP signature

Problems with mach64 on NetBSD/sparc64

[Michael]

Hello,

we ran into two problems with the ati driver.
First - it seems to screw up when switching resolution on Sun PGX64
cards ( these use a Rage XL with 8MB VRAM). The result is a monitor
reporting frequencies out of range, even when forced to use something
very conservative that works with the same monitor and a different
graphics controller.  
It works just fine with a Rage Pro.

Second - the driver seems to either ignore the BusID parameter.
Log excerpt: 
(--) PCI: (1:2:0) ATI Technologies Inc 3D Rage Pro 215GP rev 92, Mem @
0xe10 0/24, 0xe200/12, I/O @ 0xff00/8, BIOS @ 0xe102/17 
(--) PCI: (2:1:0) ATI Technologies Inc Rage XL rev 39, Mem
@0x1100/24, 0x12 00/12, I/O @ 0xff00/8, BIOS @ 0x1202/17

That's the onboard Rage Pro and a Sun PGX64 in a Sun Ultra 5

The Device section in XF86Config:
Section "Device"
### Available Driver options are:-
### Values: : integer, : float, : "True"/"False",
### : "String", : " Hz/kHz/MHz"
### [arg]: arg optional
#Option "accel" # []
#Option "crt_display"   # []
#Option "composite_sync"# []
#Option "hw_cursor" # []
#Option "mmio_cache"# []
#Option "test_mmio_cache"   # []
#Option "panel_display" # []
#Option "probe_clocks"  # []
#Option "reference_clock"   # 
#Option "shadow_fb" # []
#Option "sw_cursor" # []
Identifier  "Card0"
Driver  "ati"
VendorName  "ATI"
BoardName   "3D Rage Pro 215GP"
ChipSet "ati"
ChipId  0x4750
ChipRev 0x5c
BusID   "PCI:1:2:0"
EndSection

but XFree fails with this:
(II) ATI:  Candidate "Device" section "Card0".
(II) ATI:  Unshared PCI/AGP Mach64 in slot 1:2:0 detected.

Fatal server error:
xf86MapVidMem: could not mmap screen [s=2000,a=1200] (Invalid
argument)

So it tries to map PCI resources belonging to the Rage XL while the
Device section clearly says it should use the onboard Rage Pro. Even if
it's only probing it shouldn't fail here since the device it's supposed
to use is definitely usable - with the Rage XL removed it works as
expected.

The Xserver in question is:

XFree86 Version 4.5.0
Release Date: 16 March 2005
X Protocol Version 11, Revision 0
Build Operating System:NetBSD/sparc64 3.99.8 - The NetBSD Foundation,
Inc. 
Current Operating System: NetBSD  3.99.9 NetBSD 3.99.9
(INISHOWEN) #594: Fri Sep 23 06:57:25 EDT 2005
[EMAIL PROTECTED]:/data/src/sys/arch/sparc64/compile/INISHOWEN sparc64

any ideas?
Anything we should import from XFree -current?

have fun
Michael

PS: the Rage XL isn't mine, I'm merely forwarding problem reports I've
been unable to resolve.


pgpPP9yxkONif.pgp
Description: PGP signature

Re: Problems with mach64 on NetBSD/sparc64

[Michael]

Hello,

> If the XL has no ix86 BIOS, the ReferenceClock option (documented in 
> README.ati) likely needs to be specified.  Accurately detecting this value is 
> not possible.

Ok, I'll try that.

> > Second - the driver seems to either ignore the BusID parameter.
> > Log excerpt:
> > (--) PCI: (1:2:0) ATI Technologies Inc 3D Rage Pro 215GP rev 92, Mem @
> > 0xe10 0/24, 0xe200/12, I/O @ 0xff00/8, BIOS @ 0xe102/17
> > (--) PCI: (2:1:0) ATI Technologies Inc Rage XL rev 39, Mem
> > @0x1100/24, 0x12 00/12, I/O @ 0xff00/8, BIOS @ 0x1202/17
> 
> > That's the onboard Rage Pro and a Sun PGX64 in a Sun Ultra 5
> 
> > The Device section in XF86Config:
> > Section "Device"
> >### Available Driver options are:-
> >### Values: : integer, : float, : "True"/"False",
> >### : "String", : " Hz/kHz/MHz"
> >### [arg]: arg optional
> >#Option "accel" # []
> >#Option "crt_display"   # []
> >#Option "composite_sync"# []
> >#Option "hw_cursor" # []
> >#Option "mmio_cache"# []
> >#Option "test_mmio_cache"   # []
> >#Option "panel_display" # []
> >#Option "probe_clocks"  # []
> >#Option "reference_clock"   # 
> >#Option "shadow_fb" # []
> >#Option "sw_cursor" # []
> >Identifier  "Card0"
> >Driver  "ati"
> >VendorName  "ATI"
> >BoardName   "3D Rage Pro 215GP"
> >ChipSet "ati"
> >ChipId  0x4750
> >ChipRev 0x5c
> >BusID   "PCI:1:2:0"
> > EndSection
> 
> > but XFree fails with this:
> > (II) ATI:  Candidate "Device" section "Card0".
> > (II) ATI:  Unshared PCI/AGP Mach64 in slot 1:2:0 detected.
> 
> > Fatal server error:
> > xf86MapVidMem: could not mmap screen [s=2000,a=1200] (Invalid
> > argument)
> 
> > So it tries to map PCI resources belonging to the Rage XL while the
> > Device section clearly says it should use the onboard Rage Pro. Even if
> > it's only probing it shouldn't fail here since the device it's supposed
> > to use is definitely usable - with the Rage XL removed it works as
> > expected.
> 
> > The Xserver in question is:
> 
> > XFree86 Version 4.5.0
> > Release Date: 16 March 2005
> > X Protocol Version 11, Revision 0
> > Build Operating System:NetBSD/sparc64 3.99.8 - The NetBSD Foundation,
> > Inc.
> > Current Operating System: NetBSD  3.99.9 NetBSD 3.99.9
> > (INISHOWEN) #594: Fri Sep 23 06:57:25 EDT 2005
> > [EMAIL PROTECTED]:/data/src/sys/arch/sparc64/compile/INISHOWEN sparc64
> 
> I'd need to see a log of this.

The log and config are attached.

> > any ideas?
> > Anything we should import from XFree -current?
> 
> I think doing so for this problem is a little premature.

I was just asking in case this is a known problem.

have fun
Michael


XFree86.0.log
Description: Binary data


XF86Config
Description: Binary data


pgp1mPKo58Vyd.pgp
Description: PGP signature

Re: Problems with mach64 on NetBSD/sparc64

[Michael]

Hello,

> ATIProbe() tries to mmap() every adapter of interest in the system so
> that it can probe them.  This happens before the driver even looks at
> XF86Config information (which might not exist).
> 
> But that's not the real issue here.  The problem is that wscons on 
> NetBSD/sparc64 does not consider secondary adapters as part of the
> console. This means that multi-head cannot work as this port is
> currently coded.

I know. The NetBSD-specific code needs to open more than one device,
right now it tries to mmap() everything through a single file descriptor
which isn't going to work. There's a workaround ( /dev/xf86 ) somewhere
but that's more or less i386-specific and rather ugly.

> Either way, there's work to be done in this port's os-support layer.

Definitely.

> The only work-around is to remove the XL.  It won't work anyway, at
> least not under NetBSD/sparc64 as things currently stand.

There's no way for the ati driver to simply ignore adaptors it cannot
mmap?

have fun
Michael


pgpUQdkFQYojP.pgp
Description: PGP signature

Re: Problems with mach64 on NetBSD/sparc64

[Michael]

Hello,

> >> The only work-around is to remove the XL.  It won't work anyway, at
> >> least not under NetBSD/sparc64 as things currently stand.
> 
> > There's no way for the ati driver to simply ignore adaptors it
> > cannot mmap?
> 
> How can it, when the port FatalError's mmap() failures?

Ouch.
Hmm, many ports seem to do that. On the other hand drivers seem to check
wether xf86MapVidMem() returns NULL ( well, the ati driver does ) so -
is there a good reason to FatalError() in whatever_MapVidMem() ? If not
I'd just let it return NULL on sparc64 and see what happens.

have fun
Michael


pgpJ6qUfEpvff.pgp
Description: PGP signature

Sun Creator and XRender

[Michael]

Hello,

since the sunffb driver doesn't support the XRender extension but the
graphics processor supports alpha blending and a few other nice tricks
I've been poking around a bit to add this sort of functionality. The
problem seems to be that sunffb doesn't use xaa or the standard
framebuffer manager. so I couldn't get the included render code to work.
So my questions are:
- is there a text somewhere describing how to add xrender functionality
to a driver without using fbPictureInit() ?
- is there some more comprehensive ffb documentation available
somewhere? I think I know how alpha blending and so on is supposed to
work ( from reading the mesa driver source ) but there are still a few
more questions.

have fun
Michael


pgpG11CF8xp6j.pgp
Description: PGP signature

Re: Sun Creator and XRender

[Michael]

Hello,

> > since the sunffb driver doesn't support the XRender extension but
> > the graphics processor supports alpha blending and a few other nice
> > tricks I've been poking around a bit to add this sort of
> > functionality. The problem seems to be that sunffb doesn't use xaa
> > or the standard framebuffer manager. so I couldn't get the included
> > render code to work.
> > So my questions are:
> > - is there a text somewhere describing how to add xrender
> > functionality to a driver without using fbPictureInit() ?
> > - is there some more comprehensive ffb documentation available
> > somewhere? I think I know how alpha blending and so on is supposed
> > to work ( from reading the mesa driver source ) but there are still
> > a few more questions.
> 
> This has already been done in X.Org's repository and it is on my
> to-do-soon list to merge in.

Nice :)
So I'll stop reinventing the wheel, wait until you're done and then
import the result into NetBSD.
I wonder if they fixed DRI support too.

have fun
Michael


pgpY6xXTuIz1M.pgp
Description: PGP signature

Re: Sun Creator and XRender

[Michael]

Hello,

> > I wonder if they fixed DRI support too.
> >
> 
> DRI should work with xorg and mesa from cvs.

I'll give it a try - I have a working ( well, as far as I can tell ) DRM
for NetBSD/sparc64. The code from XFree86 4.5 more or less works but
the renderer doesn't seem to work very well ( or not at all ) with the
double-buffering extension, GL-rendered images keep flickering and
switching between GL and X contexts doesn't work either ( clipping
remains active and a few other oddities )

have fun
Michael


pgpbTI5pZOLr6.pgp
Description: PGP signature

Re: Sun Creator and XRender

[Michael]

Hello,

> > I wonder if they fixed DRI support too.
> >
> 
> DRI should work with xorg and mesa from cvs.

I'll give it a try - I have a working ( well, as far as I can tell ) DRM
for NetBSD/sparc64. The code from XFree86 4.5 more or less works but
the renderer doesn't seem to work very well ( or not at all ) with the
double-buffering extension, GL-rendered images keep flickering and
switching between GL and X contexts doesn't work either ( clipping
remains active and a few other oddities )

have fun
Michael


pgpe1lH1eHsfA.pgp
Description: PGP signature

Re: Sun Creator and XRender

[Michael]

Hello,

> This has already been done in X.Org's repository and it is on my
> to-do-soon list to merge in.

I had a look at x.org's sunffb and all they did is to rewrite
ffb_accel.c to use XAA and add a hardware-accelerated alpha-blending
function ( plus accompanying changes in ffb_driver.c to load relevant
modules and a few more or less trivial ones in other files ). Now I have
something that works, is fast but for some strange reason all text drawn
via XRender has red and blue components swapped. Only text, images are
fine. Playing with anti-aliasing parameters seems to change this too,
after disabling subpixel hinting newly started apps get it right, until
next start of the Xserver... It worked fine with the old code and
affects both KDE and GTK apps. The other changes are only reformatting
source and renaming of some macros ( XF86* -> XORG* and such ).
Any ideas?
Looks almost like an un- or misinitialized variable somewhere, defaults
to ARGB, gets overwritten when someone changes anti-aliasing parameters
and nobody noticed since ARGB is almost always right.

have fun
Michael


pgpup1nbmRMaI.pgp
Description: PGP signature

Re: Sun Creator and XRender

[Michael]

Hello,

> > I had a look at x.org's sunffb and all they did is to rewrite
> > ffb_accel.c to use XAA and add a hardware-accelerated alpha-blending
> > function ( plus accompanying changes in ffb_driver.c to load relevant
> > modules and a few more or less trivial ones in other files ). Now I have
> > something that works, is fast but for some strange reason all text drawn
> > via XRender has red and blue components swapped. Only text, images are
> > fine. Playing with anti-aliasing parameters seems to change this too,
> > after disabling subpixel hinting newly started apps get it right, until
> > next start of the Xserver... It worked fine with the old code and
> > affects both KDE and GTK apps. The other changes are only reformatting
> > source and renaming of some macros ( XF86* -> XORG* and such ).
> > Any ideas?
> > Looks almost like an un- or misinitialized variable somewhere, defaults
> > to ARGB, gets overwritten when someone changes anti-aliasing parameters
> > and nobody noticed since ARGB is almost always right.
> 
> Looks like an endian bug to me

Maybe, maybe not.
An endian bug would more likely change ARGB to BGRA but the alpha channel 
is in the right place and all images look right.
It's ARGB vs. ABGR - most PC graphics boards use ARGB, the FFB uses ABGR
and somehow this information doesn't always make it to the font renderer 
it seems ( or things are inappropriately cached, who knows, I'm toatlly 
unfamiliar with XRender and friends ). And it wouldn't change when I play 
with font rendering settings.

have fun
Michael


pgpxNgEIzG24s.pgp
Description: PGP signature

Re: Sun Creator and XRender

[Michael]

Hello,

> I had a look at x.org's sunffb and all they did is to rewrite
> ffb_accel.c to use XAA and add a hardware-accelerated alpha-blending
> function ( plus accompanying changes in ffb_driver.c to load relevant
> modules and a few more or less trivial ones in other files ). Now I
> have something that works, is fast but for some strange reason all
> text drawn via XRender has red and blue components swapped. Only text,
> images are fine. Playing with anti-aliasing parameters seems to change
> this too, after disabling subpixel hinting newly started apps get it
> right, until next start of the Xserver... It worked fine with the old
> code and affects both KDE and GTK apps. The other changes are only
> reformatting source and renaming of some macros ( XF86* -> XORG* and
> such ).
> Any ideas?
> Looks almost like an un- or misinitialized variable somewhere,
> defaults to ARGB, gets overwritten when someone changes anti-aliasing
> parameters and nobody noticed since ARGB is almost always right.

The problem is definitely in the Xserver:
- sparc64 client with X in ARGB running on a powerpc box - text colours
  are right 
- sparc64 client and X with FFB/ABGR - wrong text colours
- sparc64 client and X with mach64 or mga in ARGB - text colours are
  right 
- client on powerpc, X on sparc64 with FFB/ABGR - text colours are
  wrong
- sparc64 without Xrender support - text colours are right
... so it should be somewhere in Xrender.

There's a bug ( or at least an inconsistency ) in xf86Helper /
xf86SetWeight():

scrp->offset.red = ffs(mask.red);
scrp->offset.green = ffs(mask.green);
scrp->offset.blue = ffs(mask.blue);

this sets 1-based offsets while the rest of the code ( or at least
Xrender's PictureCreateDefaultFormats() ) expects 0-based ones.

have fun
Michael


pgpiv1nJ6B0Ms.pgp
Description: PGP signature

Re: Sun Creator and XRender

[Michael]

Hello,

> > I had a look at x.org's sunffb and all they did is to rewrite
> > ffb_accel.c to use XAA and add a hardware-accelerated alpha-blending
> > function ( plus accompanying changes in ffb_driver.c to load
> > relevant modules and a few more or less trivial ones in other files
> > ). Now I have something that works, is fast but for some strange
> > reason all text drawn via XRender has red and blue components
> > swapped. Only text, images are fine. Playing with anti-aliasing
> > parameters seems to change this too, after disabling subpixel
> > hinting newly started apps get it right, until next start of the
> > Xserver... It worked fine with the old code and affects both KDE and
> > GTK apps. The other changes are only reformatting source and
> > renaming of some macros ( XF86* -> XORG* and such ).
> > Any ideas?
> > Looks almost like an un- or misinitialized variable somewhere,
> > defaults to ARGB, gets overwritten when someone changes
> > anti-aliasing parameters and nobody noticed since ARGB is almost
> > always right.
> 
> Looks like an endian bug to me

I've found the bug.
In fbpict.c / fbComposite() calls fbCompositeSolidMask_nx8x() when
rendering text. This takes a drawable to provide the font colour as
source, one with the background color as destination and the font as
alpha mask. The problem is that gtk and KDE call this with an RGB
picture as source even when rendering directly to the screen which is
BGR. fbCompositeSolidMask*() doesn't convert the source color to the
destination picture's format - apparently it assumes RGB - which is why
text is drawn in the wrong color. Programs that render always in the
display's native format, like apparently WindowMaker, didn't have the
problem in the first place.

have fun
Michael


pgp1QrYCLg58Z.pgp
Description: PGP signature


pgplytfgHOonf.pgp
Description: PGP signature

Re: driver how-to?

[Michael]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

On Dec 1, 2006, at 10:13, [EMAIL PROTECTED] wrote:


On Fri, 1 Dec 2006, Zakharov Mikhail wrote:


Hi, everybody!

I'm going to port very old Western Digital driver from Xfree86 3.3.6
back to 4.6.x just to start my old laptop in 640x480x256 mode. I think
nobody then me interested in this driver, so it's just for fun,
nevertheless I need some guide lines to start development, for 
example,
how-to's of writing generic driver for Xfree86, directory hierarchy 
and

so on. Can somebody turn my head to the right side?


Would it happen to be for the WD90C24? Please? That's what's in my 
ThinkPad 750P, and I asked about it a while back. There was one or two 
very helpful comments that I think boiled down to these:


1. Get the new design document, read it, understand how things go.
2. Get your development environment set up.
3. Get the old source and hack away.


I'd also recommend reading the source of a relatively simple driver or 
two, candidates would be chips or tdfx ( the latter because it doesn't 
have to deal with many different variants )


And speaking of porting old drivers - I'm going to make the igs driver 
work ( hopefully ) on NetBSD/shark - has anyone worked on this in the 
past?


have fun
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (Darwin)

iQEVAwUBRXBVNMpnzkX8Yg2nAQK2dAf+O6qA/L6GQjeplOPAUhiHBok3ht8XFxeQ
sypS7NwdnyE5gOw33cpn/9piLnEPpIpjvaXy6hdYrv6QPYv1chxUB4BGFUntnWmP
oxGNWB1HCuuPDmJOCdQqdg9Q9p5EArJeQn5XHXUuqQfyqrf8BbZU0OZjv0GiqfZy
gI+cR8+6fJoQD3ZcC7g1NZkmpQjC7xAoTAtQfycLnfIrRI4r51lL08/mtMCZi/AD
bYnCweVNavwkXCjHbOAyUu53QzU3bZLDQO2P4TE/+rN+GBZUqX5OXqFnixjUzN53
e3ywySTt0TbYSuGc8sJSvyD/SjC5VcMIRGoqrykJe28NH9Hm/U1Gdw==
=Jy05
-END PGP SIGNATURE-

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

make install error with 4.3 preversion from cvs

[Michael Wahlbrink]

Hi,
I don't know if this is a known problem or what's to do now. On my linux system 
(gcc-3.2.2) I can make with no problems, but when I try to install I get the following 
error

root:~/xfree-cvs/xc# make install
[...]
gcc -m32 -c -ansi -pedantic -pipe  -I../include -I../../../include  
-I../../../include/GL  -I../../.. -I../../../exports/include   -Dlinux -D__i386__ 
-D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE 
 -D_GNU_SOURCE   -DFUNCPROTO=15 -DNARROWPROTO   -DNDEBUG  -O3 -fomit-frame-pointer 
-march=pentium4 -mfpmath=sse   mipmap.c -o unshared/mipmap.o
mipmap.c: In function `halve1Dimage_float':
mipmap.c:1268: unable to find a register to spill in class `FLOAT_REGS'
mipmap.c:1268: this is the insn:
(insn 111 109 114 (set (subreg:SF (reg/v:DI 22 rxmm1 [73]) 0)
(float:SF (reg:DI 0 rax [89]))) 170 {*floatdisf2_i387_only} (insn_list 108 
(nil))
(expr_list:REG_DEAD (reg:DI 0 rax [89])
(nil)))
mipmap.c:1268: confused by earlier errors, bailing out
make[4]: *** [mipmap.o] Error 1
make[4]: Leaving directory `/root/xfree-cvs/xc/lib/GLU/libutil'
make[3]: *** [libutil] Error 2
make[3]: Leaving directory `/root/xfree-cvs/xc/lib/GLU'
make[2]: *** [install] Error 2
make[2]: Leaving directory `/root/xfree-cvs/xc/lib'
make[1]: *** [install] Error 2
make[1]: Leaving directory `/root/xfree-cvs/xc'
make: *** [install] Error 2
root:~/xfree-cvs/xc#

Is there a known fix for it or what information do you need in addition to solve this 
problem?
micha

-- 
Michael Wahlbrink| Woeschhalde 32
 | 78052 Villingen Schwenningen
[EMAIL PROTECTED]| Germany
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Next make install error with the 4.3 preversion

[Michael Wahlbrink]

Hi, here I'm again:
got that optimization prob solved and now ran into the following prob:
[...]
install in programs/xrandr done
make[3]: Leaving directory `/root/xfree-cvs/xc/programs/xrandr'
installing in programs/xcursorgen...
make[3]: Entering directory `/root/xfree-cvs/xc/programs/xcursorgen'
gcc -m32 -O3 -fomit-frame-pointer -march=pentium4 -ansi -pedantic -pipe -I../.. 
-I../../exports/include   -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE 
-D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE  -D_GNU_SOURCE   -DFUNCPROTO=15 
-DNARROWPROTO   -c -o xcursorgen.o xcursorgen.c
rm -f xcursorgen
gcc -m32 -o xcursorgen -O3 -fomit-frame-pointer -march=pentium4 -ansi -pedantic -pipe  
   -L../../exports/lib   xcursorgen.o -lXcursor -lXext -lX11 -lpng -lm  
-Wl,-rpath-link,../../exports/lib
install -c   xcursorgen /usr/X11R6/bin/xcursorgen
+ mkdir -p /usr/X11R6/lib/X11/icons/default
install -c  index.theme /usr/X11R6/lib/X11/icons/default/index.theme
installing in programs/xcursorgen/redglass...
make[4]: Entering directory `/root/xfree-cvs/xc/programs/xcursorgen/redglass'
LD_LIBRARY_PATH=../../../exports/lib  ../../../exports/bin/xcursorgen X_cursor.cfg 
X_cursor
/bin/sh: ../../../exports/bin/xcursorgen: No such file or directory
make[4]: *** [X_cursor] Error 1
make[4]: Leaving directory `/root/xfree-cvs/xc/programs/xcursorgen/redglass'
make[3]: *** [install] Error 2
make[3]: Leaving directory `/root/xfree-cvs/xc/programs/xcursorgen'
make[2]: *** [install] Error 2
make[2]: Leaving directory `/root/xfree-cvs/xc/programs'
make[1]: *** [install] Error 2
make[1]: Leaving directory `/root/xfree-cvs/xc'
make: *** [install] Error 2

Ok, "exports/bin/xcursorgen" is not there... If I copied it by hand from 
"programs/xcursorgen" to the location where it is expected, make install went through 
the whole process w.o. errors
Heh and this error also occurs on my laptop without any optimization flags ... ;-)

Is it a bug or a feature of only my linux installation?

regards
micha

-- 
Michael Wahlbrink| Woeschhalde 32
 | 78052 Villingen Schwenningen
[EMAIL PROTECTED]| Germany
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: make install error with 4.3 preversion from cvs

[Michael Wahlbrink]

On Mon, 17 Feb 2003 14:29:06 -0500 (EST) Bryan Liesner <[EMAIL PROTECTED]> wrote:
> On Mon, 17 Feb 2003, Michael Wahlbrink wrote:
> 
> > Hi,
> > I don't know if this is a known problem or what's to do now. On my linux system 
>(gcc-3.2.2)
> >I can make with no problems, but when I try to install I get the
> >following error
> >
> > root:~/xfree-cvs/xc# make install
> > [...]
> > gcc -m32 -c -ansi -pedantic -pipe  -I../include -I../../../include
> >-I../../../include/GL  -I../../.. -I../../../exports/include
> >-Dlinux -D__i386__
> >-D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE
> >-D_BSD_SOURCE -D_SVID_SOURCE
> >-D_GNU_SOURCE   -DFUNCPROTO=15 -DNARROWPROTO   -DNDEBUG  -O3
> >-fomit-frame-pointer -march=pentium4
> >-mfpmath=sse   mipmap.c -o unshared/mipmap.o
> > mipmap.c: In function `halve1Dimage_float':
> > mipmap.c:1268: unable to find a register to spill in class `FLOAT_REGS'
> > mipmap.c:1268: this is the insn:
> > (insn 111 109 114 (set (subreg:SF (reg/v:DI 22 rxmm1 [73]) 0)
> > (float:SF (reg:DI 0 rax [89]))) 170 {*floatdisf2_i387_only} (insn_list 108 
>(nil))
> > (expr_list:REG_DEAD (reg:DI 0 rax [89])
> > (nil)))
> 
> The make did fail... On install, it tried to rebuild the bits that
> failed during the make.
> 
> Get rid of the -O3 and the -march=pentium4.  You're asking for trouble with those 
>optimizations.
> Try using just -O and recompile.
Ok after a few tests and compiles i get it, that it was the -mfpmath=sse option which 
leed there to some confused registers
but then I got the next make install Problem see mail in a new thread

thanks a lot for your help
regards
micha


-- 
Michael Wahlbrink| Woeschhalde 32
 | 78052 Villingen Schwenningen
[EMAIL PROTECTED]| Germany
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

key-bug?

[Michael Buesch]

Hi.

I have a problem with the keyboard. If I press the key with the keycode 94 
(this is the key under the "a" and right from "left-shift"), nothing appears 
on the screen.
xev says:

KeyPress event, serial 27, synthetic NO, window 0x2a1,
root 0x38, subw 0x0, time 4843886, (86,-8), root:(580,21),
state 0x10, keycode 94 (keysym 0x0, NoSymbol), same_screen YES,
XLookupString gives 0 bytes:  ""

KeyRelease event, serial 27, synthetic NO, window 0x2a1,
root 0x38, subw 0x0, time 4844099, (86,-8), root:(580,21),
state 0x10, keycode 94 (keysym 0x0, NoSymbol), same_screen YES,
XLookupString gives 0 bytes:  ""

I really don't know what to do. I think it's a bug in the CVS-xfree. (I'm 
using cvs from 8th february 2003.) I think of a bug, because it appeared 
after updating from xfree 4.2.1.
I don't want to get support from you, because I'm using development-software, 
but I just wanted to inform you about this ?bug?.

Regards Michael Buesch.

-- 



My homepage:
http://www.8ung.at/tuxsoft


Linux is like a wigwam: no gates, no windows, and an apache inside.

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

Re: key-bug?

[Michael Buesch]

Oh thank you!!!

It works now. I was really getting sad, because I'm a C++programmer and I 
really need this key. :)

 But how to fix the "bar"? Is this a real bug in xfree?

Thanks!
Regards Michael Buesch.


On Thursday 20 February 2003 18:54, Hedblom wrote:
> Hi!
>
> I have the exact same problem using xfree 4.2.99.4. Less, greater and bar
> doesnt work on keycode 94. It worked perfectly fine on previous versions.
>
> Just so you dont think this is a anomaly.
>
>  xmodmap -e "keycode 94 = less greater bar" fixes less and greater but bar
> is still missing.
>
> Cheers and thanks!
>
>
>
> On Thu, 20 Feb 2003 17:31:49 +
>
> Michael Buesch <[EMAIL PROTECTED]> wrote:
> > Hi.
> >
> > I have a problem with the keyboard. If I press the key with the keycode
> > 94 (this is the key under the "a" and right from "left-shift"), nothing
> > appears on the screen.
> > xev says:
> >
> > KeyPress event, serial 27, synthetic NO, window 0x2a1,
> > root 0x38, subw 0x0, time 4843886, (86,-8), root:(580,21),
> > state 0x10, keycode 94 (keysym 0x0, NoSymbol), same_screen YES,
> > XLookupString gives 0 bytes:  ""
> >
> > KeyRelease event, serial 27, synthetic NO, window 0x2a1,
> > root 0x38, subw 0x0, time 4844099, (86,-8), root:(580,21),
> > state 0x10, keycode 94 (keysym 0x0, NoSymbol), same_screen YES,
> > XLookupString gives 0 bytes:  ""
> >
> > I really don't know what to do. I think it's a bug in the CVS-xfree. (I'm
> > using cvs from 8th february 2003.) I think of a bug, because it appeared
> > after updating from xfree 4.2.1.
> > I don't want to get support from you, because I'm using
> > development-software, but I just wanted to inform you about this ?bug?.
> >
> > Regards Michael Buesch.
> >
> > --
> >
> >
> > 
> > My homepage:
> > http://www.8ung.at/tuxsoft
> >
> >
> > Linux is like a wigwam: no gates, no windows, and an apache inside.
> >
> > ___
> > Devel mailing list
> > [EMAIL PROTECTED]
> > http://XFree86.Org/mailman/listinfo/devel
>
> ___
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel

-- 



My homepage:
http://www.8ung.at/tuxsoft


Linux is like a wigwam: no gates, no windows, and an apache inside.

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

Re: key-bug?

[Michael Buesch]

hi.

setxkbmap -model pc105
works for me. But changing it in XF86Config to pc105 doesn't work.

regards Michael Buesch.



On Friday 21 February 2003 13:35, Oliver Welter wrote:
> I had the same problem, but I solved it with the changing of the
> keyboard-model:
>
> setxkbmap -model pc102
>
> I also tried to change this in /etc/X11/XF6Config
> but it didn't worked.
>
> For some unexpected reason the X-Server doesn't pay attention to the
> config-file.
>
> I was not able to change the model or even the language.
>
> It refers to standard model pc101 everytime I start the X-Server.
> ___
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel

-- 



My homepage:
http://www.8ung.at/tuxsoft


Linux is like a wigwam: no gates, no windows, and an apache inside.

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

Re: key-bug?

[Michael Buesch]

On Friday 21 February 2003 18:56, Mikael Andersson wrote:
> On Friday 21 February 2003 13.35, Oliver Welter wrote:
> > I had the same problem, but I solved it with the changing of the
> > keyboard-model:
> >
> > setxkbmap -model pc102
> >
> > I also tried to change this in /etc/X11/XF6Config
> > but it didn't worked.
>
> XF86Config-4 is the file you should edit if that wasn't the one you
> edited.

I edited the right one. :)
On my LFS it is /etc/X11/XF86Config
(I have no XF3.x installed)

>
> > For some unexpected reason the X-Server doesn't pay attention to the
> > config-file.
> >
> > I was not able to change the model or even the language.
> >
> > It refers to standard model pc101 everytime I start the X-Server.
> > ___
> > Devel mailing list
> > [EMAIL PROTECTED]
> > http://XFree86.Org/mailman/listinfo/devel
>
> /regards Mikael Andersson
> ___
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel

-- 



My homepage:
http://www.8ung.at/tuxsoft


Linux is like a wigwam: no gates, no windows, and an apache inside.

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

Es geht um Ihr Geld

[Michael Steiner]

Wir zahlen 10-15 Cent pro Klick für Werbung!

http://www.ero4click.com/cgi-bin/partner/ref.pl?dis 
 
Die Vergütung, der auf Ihren Seiten eingeblendeten Werbung erfolgt im 
PayPerClick Verfahren. Das heisst, Sie bekommen für jeden Klick, welche 
Besucher Ihrer Seite auf einen Werbe-Banner tätigen, 0.10 EUR 
gutgeschrieben.Bannerwerbung ist die beliebteste und etablierteste 
Werbeform im World Wide Web.

Wenn sie einen Webmaster werben erhalten sie 10% von dessen Umsatz!

Ihre Vorteile:

Sie können aus vielen verschiedenen Bannern wählen.
 
Die Teilnahme ist für Sie völlig kostenlos und kann jederzeit gekündigt 
werden. 

Die Abwicklung sämtlicher Klicks und Zahlungen wird von ero4click.com 
erledigt.

Sehr hohe Vergütungen der Klicks.Sie verdienen mindestens 10 Cent pro 
Klick.Bei einer guten Zielgruppe zahlen wir ihnen bis zu 15 Cent pro Klick.  

Sie haben jederzeit passwortgeschützten Zugriff auf Ihre  Benutzerdaten und 
Statistiken.
 
Die Auszahlungen erfolgen jeweils am Monatsende.Sie müssen mindestens 20 
Euro verdient haben um eine Auszahlung zu erhalten.
 
Garantierte Auszahlung ab 20 Euro Guthaben.

Habe damit sehr gute Erfahrungen gemacht!


http://www.ero4click.com/cgi-bin/partner/ref.pl?dis

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

Equipment Leasing

[Michael Wald]

First Pacific Funding 

Michael Wald
National Account Manager
805 Kirkland Avenue Suite 200
Kirkland, WA 98033
Telephone 877-953-2733 ext. 224
Fax 800-419-5604
 

As an established leader in the industry, First Pacific Funding
looks forward to being your partner in Equipment Lease Financing. Our many
years of
successful experience will assure high approval ratios, low rates and great
service. The following services and tools, when used effectively, will help
you increase your sales. They include:

- 90 day deferred payments
- $25.00 down (no 1st and last payment)
- $100.00 a month for the first seven months
- Step payment (reduced payment for one full year)


* Daily status reports faxed or called in to you
* Fast and flexible credit decisions (2 to 24 hours)
* High approval rates
* Leasing for both new and used equipment
* Applications by telephone
* Pre-funding available
* No financials required under $75,000
* Start-Up Business Programs Available 
* 100% Software Financing
* Soft costs (install charges) can be included
* First Pacific Funding handles all the paperwork
* Funding within 24 hours
* Partnership and National Account Programs

We look forward to working with you in the near future. If you have any
questions, please call me anytime.

Sincerely,
Michael Wald

National Account Manager
First Pacific Funding 
877-953-2733 Ext. 224
Fax 800-419-5604


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

XFree86, XAA and COMPOSITE

[Michael Matz]

Hi,

[please leave me CC'ed, I'm not (yet?) subscribed to this list]

I ported over Keith Packards new extensions (COMPOSITE and DAMAGE) from
the freedesktop Xserver to Xfree86, which seems to have worked more or
less.  See http://ktown.kde.org/~matz/BuntX.png which shows XFree86 on a
mga card, with those extensions (plus XFIXES) and xcompmgr running for the
translucent windows with shadow.  To make this work I had to disable XAA,
though (i.e.  "Accel" "off").

If I leave it on, the windows content is totally off (i.e. I get shadows
around where the windows logically are, and I can move them, just the
content shows a mixture of background from somewhere else, or anything,
just not the real content).

The way COMPOSITE works is by allocating a Pixmap for each toplevel
window, and setting it with pScreen->SetWindowPixmap.  It then expects the
rest of the xserver to render into these pixmaps for all normal render
requests, and provides a mean to copy those pixmaps back to the screen
(possibly in fancy ways).

Of course this will be fast only if that pixmap lies in offscreen
video-mem and the graphic chip is used for rendering into it (although
theoretically it all works if it's somewhere else, it just becomes
slower).

So, when XAA is active, one of the following things goes wrong:
  * it doesn't render into the window pixmap
  * it's not able to correctly blit back the window pixmap to the screen
  * something else ;)

My question: is XAA supposed to handle the case of rendering into such a
pixmap tacked to a window at all, or do I have to implement some magic
there?  I looked at xaa/*.c but I have some difficulties understanding all
the different kinds of indirections ;-)  At least I couldn't find a
definite place where the rendering GCOps would look at GetWindowPixmap,
like for instance the fb driver does (through the use of fbGetDrawable).

In a first iteration I would probably already be satisfied if not the chip
is used to render into the pixmap, but simply calls into the upper layers
of the server to do that, i.e. basically

  Graphical-xaa-op (drawable)
if (drawable == WINDOW
 && drawable-has-window-pixmap)
  return call-upper-op (drawable->GetWindowPixmap);
  /* or call-upper-op (drawable) ?  */
do accelerated stuff on drawable

Is it indeed the case that this isn't expected by XAA at all (although the
possibility of having a window pixmap is already in the server before
Keiths additions,  Get/SetWindowPixmap seems to be part of XFree86 since
1998).

Sorry if those are stupid questions, I'm a GCC hacker in my day job, I
just have vacation ;-)  Someone wants to lend me a helping hand?
Btw. my current patch is at http://ktown.kde.org/~matz/fdo-2-xf86-5.diff .


Ciao,
Michael.


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

Re: XFree86, XAA and COMPOSITE

[Michael Matz]

Hi,

On Thu, 20 Nov 2003, Mark Vojkovich wrote:

>   Current XAA only supports rendering to a single surface where the
> location to draw at is indicated by pDrawable->x and pDrawable->y.

Yeah, I figured that too after staring at the xaa sources for a day ;-)
Hmm.

> It doesn't know anything about alternate storage locations for windows.
> And it probably blows all the GC validation out of the water because
> drawables that it previously thought were always in hardware (windows),
> are now possibly in system memory.

Well, I thought XAAValidateGC would be usable for this, wouldn't it?

> My first impression is that expecting GCOps to redirect to Pixmaps is

Redirecting to Pixmaps on the graphic card, though, not to general
pixmaps.

> the wrong implementation and the Window->Pixmap redirection should have
> happened transparently in a wrapper higher up.

I don't see where.  Or rather, if that pixmap is on the graphics cards one
would want to use accelerated functions to draw into it.  So somehow the
XAA function would need to be extended not to expect a ScreenPtr, but a
Drawable (or something), which could either be the screen pixmap or some
other (which has to be on the graphics card).

But as long as one wants to use acceleration to draw into them, you
somehow have to integrate the indirection into XAA.  This could also be
done by copying all XAA functions which take a Screen to also have a
version taking a pixmap, and use that set as GCOps for windows with
alternate storage.  But this seems silly as this could probably be done
also by changing the current XAA GC functions.

Initially I thought that maybe the existing offscreen pixmap support in
XAA would be usable.  I mean it somehow does support Drawables which are
IS_OFFSCREEN_PIXMAP().  I'm still scratching my head if I can use it or
not.

Hmm, I think I'll try my luck with converting the current GC
Ops implementors to not take a Screen, but (or additionally) a pixmap, or
drawable.  It just seems to be quite a bit of work :-(

> Also, how is OpenGL supposed to work with something like this?

I don't understand.  Either the "backend" can draw accelerated into
offscreen pixmap, or it can't.  If the backend is OpenGL or something else
doesn't seem to matter.


Ciao,
Michael.

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

Re: External FreeType build problem

[Michael Lampe]

David Dawes wrote:

Do the gcc people give a reason for not allowing a system directory to
be "blessed" with -I?
I wouldn't call it a "reason", but the manual puts it like this:

"(...) the option is ignored to ensure that the default search order for
system directories and the special treatment of system headers are not
defeated".
OK, I see.  This is to prevent system directories being searched
before directories containing gcc-specific replacements for system
headers.
Even worse. Current CVS fails to build xterm with gcc 2.95.3 because of 
this '-I/usr/include':

gcc -c -O2 -march=i686 -fomit-frame-pointer -ansi -pedantic -Wall 
-Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes 
-Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef 
-I../../exports/include -I/usr/include -I/usr/include/freetype2 
-I../../exports/include/X11  -I../.. -I../../exports/include 
-I../../exports/include   -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L 
-D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE 
-D_GNU_SOURCE  -DNO_MESSAGE_CATALOG -DFUNCPROTO=15 -DNARROWPROTO   -I. 
  -DSCROLLBAR_RIGHT -DOPT_WIDE_CHARS -DOPT_LUIT_PROG -DXRENDERFONT 
-DXFREE86_FT2 -DPROJECTROOT=/opt/XFree86-4.4charproc.c
In file included from charproc.c:123:
/usr/include/error.h:26: parse error

This is because gcc now includes /usr/include/error.h instead of error.h 
from programs/xterm.

One should never put an explicit '-I/usr/include' or 
'-I/usr/local/include' in CFLAGS because this can lead to all sorts of 
strange behaviour.

The same holds for '-L/usr/lib' or '-L/usr/local/lib' in LDFLAGS.

Michael

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

Re: External FreeType build problem

[Michael Lampe]

David Dawes wrote:

Even worse. Current CVS fails to build xterm with gcc 2.95.3 because of 
this '-I/usr/include':

gcc -c -O2 -march=i686 -fomit-frame-pointer -ansi -pedantic -Wall 
-Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes 
-Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef 
-I../../exports/include -I/usr/include -I/usr/include/freetype2 
-I../../exports/include/X11  -I../.. -I../../exports/include 
-I../../exports/include   -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L 
-D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE 
-D_GNU_SOURCE  -DNO_MESSAGE_CATALOG -DFUNCPROTO=15 -DNARROWPROTO   -I. 
  -DSCROLLBAR_RIGHT -DOPT_WIDE_CHARS -DOPT_LUIT_PROG -DXRENDERFONT 
-DXFREE86_FT2 -DPROJECTROOT=/opt/XFree86-4.4charproc.c
In file included from charproc.c:123:
/usr/include/error.h:26: parse error

This is because gcc now includes /usr/include/error.h instead of error.h 
from programs/xterm.

One should never put an explicit '-I/usr/include' or 
'-I/usr/local/include' in CFLAGS because this can lead to all sorts of 
strange behaviour.
Never /usr/local/include??  That's ridiculous.  How are you deciding which
ones are allowed and which are not?
The point is (I'm refering to gcc here) that /usr/local/include and 
/usr/include are searched by default but in this order:

 
 /usr/local/include
 /usr/lib/gcc-lib/i486-linux/2.95.3/../../../../i486-linux/include
 /usr/lib/gcc-lib/i486-linux/2.95.3/include
 /usr/include
In this order you normally get what you expect. For example, if you have 
a more recent version of some library installed in /usr/local than in 
/usr. Putting '-I/usr/include' in CFLAGS changes this order and produces 
 unexpected results, especially if you don't do it yourself but some 
'foo-config --clags'. Another example is the above xterm build error.

I think this is the real reason why newer gcc's simply ignore 
'-I/usr/include'

Besides, most sane 'foo-config' scripts contain for that very reason 
something like this:

- from freetype-config -

if test "$echo_cflags" = "yes" ; then
 cflags="-I${prefix}/include/freetype2"
 if test "${prefix}/include" != "/usr/include" ; then  <==
  echo -I${prefix}/include $cflags
 else
  echo $cflags
 fi
fi
if test "$echo_libs" = "yes" ; then
 libs="-lfreetype -lz"
 if test "${exec_prefix}/lib" != "/usr/lib" ; then <==
  echo -L${exec_prefix}/lib $libs
 else
  echo $libs
 fi
fi
-

'-I/usr/local/include' and '-L/usr/local/lib' seem, on second thought, 
not to be a problem.

If you use these and have local headers that might conflict,
I guess every unix has /usr/include/error.h

then
you must put -I. in explicitly first.  Then there is no ambiguity.
I'd say that's what needs to happen for xterm/Imakefile.
Would obviously solve the xterm build problem. As would removing 
'-I/usr/include'.

If someone wants to try builds that currently rely on -I/usr/include and
make sure they work correctly when they are removed, please do, and send
reports of any problems.
Which systems do not search in /usr/include automatically?

Michael



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

XFree86 developer documentation

[Michael Berhanu]

Hi there, is there any documentation - either in 
the form of tutorials or specifications, of how XFree86 works?
 
Thanks.

Re: embed the fixed font in the X server binary

[Michael Taylor]

Torgeir Veimo wrote:
> The dreaded 
> 
> Fatal server error:
> could not open default font 'fixed'
> 
> - can happen at the least expected times.
> 
> To the point: wouldn't it be benecifial to embed the fixed font in the X
> server binary itself? It would harden the x server tremendously in case
> of system failures. On my system the fixed font, which is really the
> 6x13-ISO8859-1.pcf.gz is 4366 bytes big. 

No need. Fonts could be specified via FontPath in the XF86Config file, so as not
to solely depend on the font server (xfs in this case). I believe someone has
suggested this idea as a change in default configuration recommended.

E.g.

Section "Files"
[...]
FontPath   "unix/:7100"
FontPath   "/usr/X11R6/lib/X11/fonts/misc"
EndSection

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

Re: So what's up now?

[Michael Taylor]

Jewel Kilcher wrote:
> Is xf86 dead in the water?  What decisions did the core team hold over
> the project?  Don't mean to bother anyone, but I don't want to see
> this die.

Not dead.

http://www.mail-archive.com/xfree86%40xfree86.org/msg11932.html
http://www.mail-archive.com/devel%40xfree86.org/msg04639.html

Perhaps this could be clarified on the XFree86 front page.

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

Re: Debian

[Michael Taylor]

Marc Aurele La France wrote:
> This came up while helping some clueless Windows exile(e):
> 
> So, how come Debian "stable" is still at XFree86 4.1?

Because that is what they had in 'testing' when they released Debian 3.0r0
(woody) back in July 2002. Currently their 'testing' aka sarge has XFree86 4.2.1
plus patches (...-12.1) which is scheduled to be made their 'stable' release
possibly in Feburary I believe.

Debian's Changelog for XFree86 4.2.1


I don't understand the Debian policy but it would be nice if at least 4.3.0 was
included in their release of sarge as stable next month.


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

Re: Debian

[Michael Taylor]

Sven Luther wrote:
> On Thu, Jan 22, 2004 at 05:12:28PM -0500, Michael Taylor wrote:

>>I don't understand the Debian policy but it would be nice if at least 4.3.0 was
>>included in their release of sarge as stable next month.
> 
> 
> A debian/sarge release next month would most assuredly be premature.

My (limited) understanding is that there plan to release a new stable in 2004,
with the goal of being sooner than later. Is this correct?

What version of XFree86 will the new (future 2004) stable include 4.2.1 or 4.3.0?

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

Re: Manufacturers who fully disclosed specifications for agp cards?

[Michael Taylor]

Ryan Underwood wrote:
> On Tue, Feb 03, 2004 at 04:24:24AM -0500, Mike A. Harris wrote:
> 
>>>   Matrox (82)
>>
>>None of Matrox's specs are public, but some where once avail
>>under NDA.  They no longer appear to be available from their
>>private developer website, unless I am looking in the wrong
>>place.
> 
> 
> AFAIK they don't answer developer relations requests anymore for open
> source folks.  At least I've never had a request accepted, and I've been

Does any developers here have access to specs for new-ish Matrox cards like the
Matrox Millennium P-Series: P650 (especially this model), P750, and possibly the
Parhelia series?

I'd be interested in knowing whether it is likely that open source drivers for
these would be available.

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

Xv and resolution loss on matrox cards

[Michael Lampe]

I'm rehashing an old thread from xpert, 
http://marc.theaimsgroup.com/?t=9772209053&r=1&w=2 and propose the 
following patch, derived from how mga_vid.c (kernel module for Matrox 
BES from mplayer) programs the card. It basically disables that 
'accelerated 2x horizontal zoom' thing which causes the problem. (With 
this option on, it looks like information from only every other pixel is 
used.)

It also turns back on 'chroma upsampling' (which was only turned off in 
a failed attempt to solve the issue, see quoted thread) and changes the 
vsync position to 2 (a la mga_vid.c, seems as good a constant as what 
was used before but is simpler).

A good example for testing is 
http://cox.iwr.uni-heidelberg.de/~ug/films/stefan.mov

-Michael

Index: programs/Xserver/hw/xfree86/drivers/mga/mga_video.c
===
RCS file: /cvs/xc/programs/Xserver/hw/xfree86/drivers/mga/mga_video.c,v
retrieving revision 1.34
diff -u -r1.34 mga_video.c
--- programs/Xserver/hw/xfree86/drivers/mga/mga_video.c 20 Feb 2004 16:59:49 - 
 1.34
+++ programs/Xserver/hw/xfree86/drivers/mga/mga_video.c 15 Apr 2004 12:35:35 -
@@ -578,48 +578,29 @@
 short src_w, short src_h,
 short drw_w, short drw_h
 ){
+#define VSYNC_POS 2
+
 MGAPtr pMga = MGAPTR(pScrn);
-int tmp, hzoom, intrep;
-int maxOverlayClock;
+int tmp, intrep;
 
 CHECK_DMA_QUIESCENT(pMga, pScrn);
 
-/* got 48 scanlines to do it in */
-tmp = INREG(MGAREG_VCOUNT) + 48;
-/* FIXME always change it in vertical retrace use CrtcV ?*/
-if(tmp > pScrn->currentMode->CrtcVTotal)
-   tmp -= 49; /* too bad */
-else
-tmp = pScrn->currentMode->CrtcVTotal -1;
-
-tmp = pScrn->currentMode->VDisplay +1;
-/* enable accelerated 2x horizontal zoom when pixelclock >135MHz */
-
-if ((pMga->ChipRev >= 0x80) || (pMga->Chipset == PCI_CHIP_MGAG550)) {
-   /* G450, G550 */
-   maxOverlayClock = 234000;
-} else {
-   maxOverlayClock = 135000;
-}
-
-hzoom = (pScrn->currentMode->Clock > maxOverlayClock) ? 1 : 0;
-
 switch(id) {
 case FOURCC_UYVY:
-   OUTREG(MGAREG_BESGLOBCTL, 0x00c0 | (3 * hzoom) | (tmp << 16));
+   OUTREG(MGAREG_BESGLOBCTL, 0x00c0 | (VSYNC_POS << 16));
break;
 case FOURCC_YUY2:
 default:
-   OUTREG(MGAREG_BESGLOBCTL, 0x0080 | (3 * hzoom) | (tmp << 16));
+   OUTREG(MGAREG_BESGLOBCTL, 0x0080 | (VSYNC_POS << 16));
break;
 }
 
 OUTREG(MGAREG_BESA1ORG, offset);
 
 if(y1 & 0x0001)
-   OUTREG(MGAREG_BESCTL, 0x00040c41);
+   OUTREG(MGAREG_BESCTL, 0x00050c41);
 else 
-   OUTREG(MGAREG_BESCTL, 0x00040c01);
+   OUTREG(MGAREG_BESCTL, 0x00050c01);
  
 OUTREG(MGAREG_BESHCOORD, (dstBox->x1 << 16) | (dstBox->x2 - 1));
 OUTREG(MGAREG_BESVCOORD, (dstBox->y1 << 16) | (dstBox->y2 - 1));
@@ -640,7 +621,7 @@
 OUTREG(MGAREG_BESVISCAL, tmp & 0x001c);
 
 intrep = ((drw_w == src_w) || (drw_w < 2)) ? 0 : 1;
-tmp = (((src_w - intrep) << 16)/(drw_w - intrep)) << hzoom;
+tmp = (((src_w - intrep) << 16)/(drw_w - intrep));
 if(tmp >= (32 << 16))
tmp = (32 << 16) - 1;
 OUTREG(MGAREG_BESHISCAL, tmp & 0x001c);

Re: Xv and resolution loss on matrox cards

[Michael Lampe]

Seems like the BES regs are double bufferd, therefore commit them 
_after_ they are set. New patch:
Index: programs/Xserver/hw/xfree86/drivers/mga/mga_video.c
===
RCS file: /cvs/xc/programs/Xserver/hw/xfree86/drivers/mga/mga_video.c,v
retrieving revision 1.34
diff -u -r1.34 mga_video.c
--- programs/Xserver/hw/xfree86/drivers/mga/mga_video.c 20 Feb 2004 16:59:49 - 
 1.34
+++ programs/Xserver/hw/xfree86/drivers/mga/mga_video.c 16 Apr 2004 17:09:29 -
@@ -578,48 +578,19 @@
 short src_w, short src_h,
 short drw_w, short drw_h
 ){
+#define VSYNC_POS 2
+
 MGAPtr pMga = MGAPTR(pScrn);
-int tmp, hzoom, intrep;
-int maxOverlayClock;
+int tmp, intrep;
 
 CHECK_DMA_QUIESCENT(pMga, pScrn);
 
-/* got 48 scanlines to do it in */
-tmp = INREG(MGAREG_VCOUNT) + 48;
-/* FIXME always change it in vertical retrace use CrtcV ?*/
-if(tmp > pScrn->currentMode->CrtcVTotal)
-   tmp -= 49; /* too bad */
-else
-tmp = pScrn->currentMode->CrtcVTotal -1;
-
-tmp = pScrn->currentMode->VDisplay +1;
-/* enable accelerated 2x horizontal zoom when pixelclock >135MHz */
-
-if ((pMga->ChipRev >= 0x80) || (pMga->Chipset == PCI_CHIP_MGAG550)) {
-   /* G450, G550 */
-   maxOverlayClock = 234000;
-} else {
-   maxOverlayClock = 135000;
-}
-
-hzoom = (pScrn->currentMode->Clock > maxOverlayClock) ? 1 : 0;
-
-switch(id) {
-case FOURCC_UYVY:
-   OUTREG(MGAREG_BESGLOBCTL, 0x00c0 | (3 * hzoom) | (tmp << 16));
-   break;
-case FOURCC_YUY2:
-default:
-   OUTREG(MGAREG_BESGLOBCTL, 0x0080 | (3 * hzoom) | (tmp << 16));
-   break;
-}
-
 OUTREG(MGAREG_BESA1ORG, offset);
 
 if(y1 & 0x0001)
-   OUTREG(MGAREG_BESCTL, 0x00040c41);
+   OUTREG(MGAREG_BESCTL, 0x00050c41);
 else 
-   OUTREG(MGAREG_BESCTL, 0x00040c01);
+   OUTREG(MGAREG_BESCTL, 0x00050c01);
  
 OUTREG(MGAREG_BESHCOORD, (dstBox->x1 << 16) | (dstBox->x2 - 1));
 OUTREG(MGAREG_BESVCOORD, (dstBox->y1 << 16) | (dstBox->y2 - 1));
@@ -640,11 +611,20 @@
 OUTREG(MGAREG_BESVISCAL, tmp & 0x001c);
 
 intrep = ((drw_w == src_w) || (drw_w < 2)) ? 0 : 1;
-tmp = (((src_w - intrep) << 16)/(drw_w - intrep)) << hzoom;
+tmp = (((src_w - intrep) << 16)/(drw_w - intrep));
 if(tmp >= (32 << 16))
tmp = (32 << 16) - 1;
 OUTREG(MGAREG_BESHISCAL, tmp & 0x001c);
 
+switch(id) {
+case FOURCC_UYVY:
+   OUTREG(MGAREG_BESGLOBCTL, 0x00c0 | (VSYNC_POS << 16));
+   break;
+case FOURCC_YUY2:
+default:
+   OUTREG(MGAREG_BESGLOBCTL, 0x0080 | (VSYNC_POS << 16));
+   break;
+}
 }
 
 static void

Re: Xv and resolution loss on matrox cards

[Michael Lampe]

David Dawes wrote:

Isn't the 'accelerated 2x horizontal zoom' thing something that is
required (because of hardware limitation) above certain clock rates?
I don't have the relevant specs handy to check.
This seems to be irrelevant in practice. With my G400 at [EMAIL PROTECTED], 
32 bpp (max my monitor can do) I could provoke some slight image 
distortion (occasional single black lines in the overlay) by running 
mplayer, glxgears and 'ls -lR /' in an xterm in parallel -- maybe there 
are better test cases. This seems to demonstrate some bandwidth 
limitation, but it doesn't occur in normal cases. At [EMAIL PROTECTED], 32 
bpp what I normally use I can't see anything at all.

So, because I don't have any specs (and if the numbers currently in the 
code are derived from specs they are way too conservative) and prefer a 
good image under normal circumstances to a bad one all the time, I 
followed mga_vid's example and ripped the whole thing out.

-Michael

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

libextmod.a does not resolve symbols in XFree86

[Michael Boccara]

Functions defined in XFree86 are not resolved in libextmod.a when referenced
as extern.
Why ?
Is there a way to help the symbol resolution ?

Thanks,

Michael Boccara

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

Re: How the screen to be Rotate 90deg

[Michael Lampe]

NaggarajaVignesh.R wrote:
  Iam trying to Rotate the Screen 90 in Red Hat Linux 9.0 with System
Configuration intel 845 graphics card .The error msg is 

X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  156 (RANDR)
  Minor opcode of failed request:  2 (RRSetScreenConfig)
  Serial number of failed request:  12
  Current serial number in output stream:  12
can any one help me .
Rotation via RANDR isn't implemented
-Michael
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

RE: libextmod.a does not resolve symbols in XFree86

[Michael Boccara]

> > Functions defined in XFree86 are not resolved in libextmod.a
> when referenced
> > as extern.
> > Why ?
> > Is there a way to help the symbol resolution ?
> >
>This is a problem you are seeing with the existing code or only
> after you modified something?   XFree86 modules can only resolve
> symbols exported by the core server.  XFree86 modules do not link
> to external libraries.
>

Interesting.
I did modify something. I am actually developing my own X11 extension, in
the extmod module. The base XFree86 code doesn't have any issue.
The symbol I am trying to resolve is defined in libdix.a
(xc/programs/Xserver/dix), which is statically linked to XFree86.
How does XFree86 export symbols explicitely ?

Thanks,

Michael


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

RE: libextmod.a does not resolve symbols in XFree86

[Michael Boccara]

Great, this worked !
Thanks a lot, Mark.

Michael

> -Original Message-
> From: Mark Vojkovich [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 14, 2004 11:30 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: RE: libextmod.a does not resolve symbols in XFree86
> 
> 
> 
> 
> On Wed, 14 Jul 2004, Michael Boccara wrote:
> 
> > > > Functions defined in XFree86 are not resolved in libextmod.a
> > > when referenced
> > > > as extern.
> > > > Why ?
> > > > Is there a way to help the symbol resolution ?
> > > >
> > >This is a problem you are seeing with the existing code or only
> > > after you modified something?   XFree86 modules can only resolve
> > > symbols exported by the core server.  XFree86 modules do not link
> > > to external libraries.
> > >
> >
> > Interesting.
> > I did modify something. I am actually developing my own X11 
> extension, in
> > the extmod module. The base XFree86 code doesn't have any issue.
> > The symbol I am trying to resolve is defined in libdix.a
> > (xc/programs/Xserver/dix), which is statically linked to XFree86.
> > How does XFree86 export symbols explicitely ?
> 
>   DIX symbols are exported in 
> xc/programs/Xserver/hw/xfree86/loader/dixsym.c
> 
> 
>   Mark.
> 
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: cvs compile failed: fbdev

[Michael Lampe]

Marc Aurele La France wrote:
They came straigt from linux-2.6.9rc1.

I realized that the cvs compiles fine with linux-2.4, but not the fbdev 
doesn't compile under 2.6.9rc1.
rc1 inserts a pointer to kernel memory into the middle of the fb_monspecs 
structure. So, either more of linux/fb.h needs to bracketed with #ifndef 
__KERNEL__, or rc1 breaks userland binary compatibility (among other things). 
In both cases, this is a kernel issue.
They will tell you it's not:
/usr/include/linux/list.h:700: warning: #warning "don't include kernel 
headers in userspace"

I don't know how to handle this properly, though.
-Michael
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: cvs compile failed: fbdev

[Michael Lampe]

Marc Aurele La France wrote:
... In both cases, this is a kernel issue.

They will tell you it's not:

/usr/include/linux/list.h:700: warning: #warning "don't include kernel 
headers in userspace"
Irrelevant.  The #include  is only there in an attempt to resolve 
the type of the inserted kernel memory list pointer.

I don't know how to handle this properly, though.
Don't assume problems with test kernels need to be resolved here.
You didn't get it. Including linux kernel headers in user space is a no 
no. See various threads about this on LKML. Bottom line: If you include 
kernel headers and your app breaks it's your fault not ours.

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

vesa.c compile breaks under 2.6 Linux kernel headers

[Michael Shell]

Recently I discovered a problem with one of the files in the XFree86
source tree - I used the 4.4.0 release, but the current CVS also has the
problem:

http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/tinyx/vesa/vesa.c

This problem will cause the build to fail when using the 2.6 (but
not 2.4) Linux kernel headers:


vesa.c: In function `toshibaDPMS':
vesa.c:1516: error: subscripted value is neither array nor pointer
make[4]: *** [vesa.o] Error 1


vesa.c resides in /programs/Xserver/hw/tinyx/vesa (formally
/programs/Xserver/hw/kdrive/vesa)

The problem occurs with line number 1486, which reads:


#define TOSH_SMM _IOWR('t', 0x90, 24)


The above is incorrect as the third argument of the Linux _IORW
macro (defined in /usr/include/asm/ioctl.h) is supposed to be
a data type, not the number of bytes to transfer. This is a common
mistake which is made in lots of existing applications. However,
because the mistake, which is harmless under 32 bit systems, breaks
under 64 bit CPUs, the 2.6 Linux Kernel introduced checking code
which triggers a compile error - and this is exactly what happens
with vesa.c. For the gory details, see the excellent article:

https://lwn.net/Articles/48354/

If my understanding is correct (and my proposed change should be
checked for correctness under 64 bit systems), then the
offending vesa.c line should read:


#define TOSH_SMM _IOWR('t', 0x90, int)


( which is similar to what was proposed in January under one of
  the Debian patches for the toshutils package:

  http://lists.debian.org/debian-glibc/2004/01/msg00114.html )

Making the above change results in clean compile on my 2.6.8.1
i586 Linux system.


 Hope this helps somebody,
 
 Michael Shell
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Resolution problems with i810 driver, Intel 915GM & 855resolution

[Michael Jastram]

, (Unknown error 999)
drmOpenDevice: Open failed
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (Unknown error 999)
drmOpenDevice: open result is -1, (Unknown error 999)
drmOpenDevice: Open failed
drmOpenByBusid: Searching for BusID pci::00:02.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 7, (OK)
drmOpenByBusid: drmOpenMinor returns 7
drmOpenByBusid: drmGetBusid reports pci::00:02.0
(II) I810(0): [drm] loaded kernel module for "i915" driver
(II) I810(0): [drm] DRM interface version 1.2
(II) I810(0): [drm] created "i915" driver at busid "pci::00:02.0"
(II) I810(0): [drm] added 8192 byte SAREA at 0xf8c49000
(II) I810(0): [drm] mapped SAREA 0xf8c49000 to 0xb7cc
(II) I810(0): [drm] framebuffer handle = 0xb002
(II) I810(0): [drm] added 1 reserved context for kernel

...

(II) I810(0): [drm] Registers = 0x9008
(II) I810(0): [drm] Back Buffer = 0xbf80
(II) I810(0): [drm] Depth Buffer = 0xbf40
(II) I810(0): [drm] ring buffer = 0xb000
(II) I810(0): [drm] textures = 0xb05a2000
(II) I810(0): [drm] dma control initialized, using IRQ 11
(II) I810(0): [drm] Initialized kernel agp heap manager, 19136512
(II) I810(0): [dri] visual configs initialized
(WW) I810(0): Failed to set up write-combining range (0xb000,0x1000)

> ... and some harmless warnings:

(WW) I810(0): Option "Rotate" is not used
(WW) I810(0): Option "CalcAlgorithm" is not used



Any help is really appreciated!  I *assume* that it should
be possible to create a new plugin for 855resolution, but
I don't know enough to do it myself.

Thanks!

- Michael


> Here is the complete mode output from the logs:

Mode: 30 (640x480)
ModeAttributes: 0x9b
WinAAttributes: 0x7
WinBAttributes: 0x0
WinGranularity: 64
WinSize: 64
WinASegment: 0xa000
WinBSegment: 0x0
WinFuncPtr: 0xc0006e5f
BytesPerScanline: 640
XResolution: 640
YResolution: 480
XCharSize: 8
YCharSize: 16
NumberOfPlanes: 1
BitsPerPixel: 8
NumberOfBanks: 1
MemoryModel: 4
BankSize: 0
NumberOfImages: 37
RedMaskSize: 0
RedFieldPosition: 0
GreenMaskSize: 0
GreenFieldPosition: 0
BlueMaskSize: 0
BlueFieldPosition: 0
RsvdMaskSize: 0
RsvdFieldPosition: 0
DirectColorModeInfo: 0
PhysBasePtr: 0xb000
LinBytesPerScanLine: 640
BnkNumberOfImagePages: 37
LinNumberOfImagePages: 37
LinRedMaskSize: 0
LinRedFieldPosition: 0
LinGreenMaskSize: 0
LinGreenFieldPosition: 0
LinBlueMaskSize: 0
LinBlueFieldPosition: 0
LinRsvdMaskSize: 0
LinRsvdFieldPosition: 0
MaxPixelClock: 23000
Mode: 32 (800x600)
ModeAttributes: 0x9b
WinAAttributes: 0x7
WinBAttributes: 0x0
WinGranularity: 64
WinSize: 64
WinASegment: 0xa000
WinBSegment: 0x0
WinFuncPtr: 0xc0006e5f
BytesPerScanline: 832
XResolution: 800
YResolution: 600
XCharSize: 8
YCharSize: 16
NumberOfPlanes: 1
BitsPerPixel: 8
NumberOfBanks: 1
MemoryModel: 4
BankSize: 0
NumberOfImages: 23
RedMaskSize: 0
RedFieldPosition: 0
GreenMaskSize: 0
GreenFieldPosition: 0
BlueMaskSize: 0
BlueFieldPosition: 0
RsvdMaskSize: 0
RsvdFieldPosition: 0
DirectColorModeInfo: 0
PhysBasePtr: 0xb000
LinBytesPerScanLine: 832
BnkNumberOfImagePages: 23
LinNumberOfImagePages: 23
LinRedMaskSize: 0
LinRedFieldPosition: 0
LinGreenMaskSize: 0
LinGreenFieldPosition: 0
LinBlueMaskSize: 0
LinBlueFieldPosition: 0
LinRsvdMaskSize: 0
LinRsvdFieldPosition: 0
MaxPixelClock: 23000
Mode: 34 (1024x768)
ModeAttributes: 0x9b
WinAAttributes: 0x7
WinBAttributes: 0x0
WinGranularity: 64
WinSize: 64
WinASegment: 0xa000
WinBSegment: 0x0
WinFuncPtr: 0xc0006e5f
BytesPerScanline: 1024
XResolution: 1024
YResolution: 768
XCharSize: 8
YCharSize: 16
NumberOfPlanes: 1
BitsPerPixel: 8
NumberOfBanks: 1
MemoryModel: 4
BankSize: 0
NumberOfImages: 15
RedMaskSize: 0
RedFieldPosition: 0
GreenMaskSize: 0
GreenFieldPosition: 0
BlueMaskSize: 0
BlueFieldPosition: 0
RsvdMaskSize: 0
RsvdFieldPosition: 0
DirectColorModeInfo: 0
PhysBasePtr: 0xb000
LinBytesPerScanLine: 1024
BnkNumberOfImagePages: 15
LinNumberOfImagePages: 15
LinRedMaskSize: 0
LinRedFieldPosition: 0

Re: Resolution problems with i810 driver, Intel 915GM & 855resolution

[Michael Jastram]

Hi Mark,

> I used to play around with 855resolution, trying to get 1280x720 for
> HDTV on my i865.

I took the time to look at the 855resolution code, and you're right,
it's not that complicated.

> IIRC there was a routine that enabled write mode in the BIOS, then
> another routine to make it read-only again

Yup, found it:

static void unlock_bios(void) {
outl(0x805a, 0xcf8);
outb(0x33, 0xcfe);
}

static void relock_bios(void) {
outl(0x805a, 0xcf8);
outb(0x11, 0xcfe);
}

> let me know if you have any trouble and I can probably generate a
> diff.

That would be really cool - because I have no idea where the magic
numbers come from, and which ones would be appropriate for the 915GM.
I looked at the outl/outb documentation, but obviously the values are
hardware specific.  Can you, or anybody on the list, give me some
pointers?

Thanks!

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

Re: Resolution problems with i810 driver, Intel 915GM & 855resolution

[Michael Jastram]

Christian,

> The registers to change are documented in the datasheet of the
> specific chipset by Intel. You'll have to look for the PAM registers
> (at least that's what they're called for i8xx-chipsets).

That was really helpful.  I was surprised to find the datasheets
readily available for download from Intel.  I downloaded the one for
the 915GM and also 855GM, so I could understand the existing
855resolution code better.

915GM: http://www.intel.com/design/mobile/datashts/305264.htm
855GM: http://www.intel.com/design/chipsets/datashts/252615.htm

I still don't understand the following code completely (original code
for 855GM):

// Tell the card which register to write:
outl(0x805a, 0xcf8);

// Send the data:
outb(0x33, 0xcfe);

Now, the first statement makes sense, kind of.  The format is
specified in section 4.6.1 (page 56) of the 855GM spec.  Writing four
bytes to 0xcf8 populates CONFIG_ADDRESS.  The value 0x805a means:

- Enable [31]
- Bus 0 [23:16]
- Device 0 [15:11]
- Function Number 0 [10:8]
- Register 0x16 [7:2]

Next, Writing is enabled by setting bits 0, 1, 4 and 5, as documented
in section 4.8.17 (page 70).  In fact, this enables two, not just one
PAM register for R/W.  But which ones?

I don't understand where 0xcfe comes from!  CONFIG_DATA starts at
0xcfc (4.6.2., page 57); which of the 14 PAM Registers are we writing
to?  Table 26 (page 71) lists offsets for the PAMs, but they don't
make sense to me.  Section 5.4.5 (page 132) seems to cover this, but I
don't get it.  Also, where does Register 0x16 come from?

And last, once I am ready to modify this for 915GM: Which bus and
device does my machine use?  According to the X log files, it's PCI
00:02:0 - so do I use bus 0, device 2, function number 0?

Many questions... I am grateful for any help or other pointers.

- Michael

--
Michael Jastram - [EMAIL PROTECTED] - http://jastram.de/
PGP: 9301 1A1A 58C6 2433 4EA0A040 A5AE 4122 12C1 EB80
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: Resolution problems with i810 driver, Intel 915GM & 855resolution

[Michael Jastram]

> But I just received an email from Steve Tomljenovic: He already ported
> 855resolution to the i915. You can find his 915resolution at:
> http://www.geocities.com/stomljen/

You rock!  It works flawlessly, right out of the box!  Thank you both,
Steve and Christian.

> Addressing these registers works as follows: (snip)

Thanks for that info, too.  Initially the spec was quite intimidating,
but it's not that bad after all, and quite interesting.  It's nice to
get a better feeling on how things work under the hood.

Again, you did me a huge favor!

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

xaa vs. WriteImage()

[Michael Lorenz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

I noticed the following - XAACopyArea() only attempts to use  
accelerated WriteImage() when writing to a DRAWABLE_WINDOW but not on  
off-screen pixmaps. I used the following changes to make it work:


diff -u -w -r1.1.1.3 xaaCpyArea.c
- --- xaaCpyArea.c  9 Jun 2001 15:09:02 -   1.1.1.3
+++ xaaCpyArea.c3 Mar 2008 20:51:05 -
@@ -64,9 +64,16 @@
 return (XAABitBlt( pSrcDrawable, pDstDrawable,
pGC, srcx, srcy, width, height, dstx, dsty,
XAADoBitBlt, 0L));
+   } else {
+   if(infoRec->ScreenToScreenBitBlt &&
+CHECK_ROP(pGC,infoRec->ScreenToScreenBitBltFlags) &&
+CHECK_ROPSRC(pGC,infoRec->ScreenToScreenBitBltFlags) &&
+CHECK_PLANEMASK(pGC,infoRec->ScreenToScreenBitBltFlags))
+return (XAABitBlt( pSrcDrawable, pDstDrawable,
+   pGC, srcx, srcy, width, height, dstx, dsty,
+   XAADoImageWrite, 0L));
}
 }

have fun
Michael

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBR8yJLspnzkX8Yg2nAQJB1Af/WJURJ35CVffglB7R3mZm6oNZARbxmiGo
yUn2se/QF5MmuuUqOWexdyGhw6W1rpzlDUdpvLhaOV0zFXW1Jbt9zQLFtWkY58TE
2esnUzJNGrt5HZ7egcjfQvKcvLHePJp8N+nBObY8skQhEQJIrgRdRUCRF6NwPF2M
P7erfgmTBOu3nZpRAoDAED5A7DQ3BAvR9NG6WOUGVWq+5OB1vk9JJ/paR0Dmy/vQ
vtnyn0mO8SMvYd4vy8YVgQN27O4tuSojdJW4A9cFM775fOwbdZ98W6w6pHhKCzkC
OP1kylCXNu9pth4MzgLa0b/7lyEs8z3Zq3M/eihpiQKz6Hnqji98cQ==
=67pe
-END PGP SIGNATURE-
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: xaa vs. WriteImage()

[Michael Lorenz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

On Mar 4, 2008, at 15:37, Marc Aurele La France wrote:


On Mon, 3 Mar 2008, Michael Lorenz wrote:

I noticed the following - XAACopyArea() only attempts to use  
accelerated WriteImage() when writing to a DRAWABLE_WINDOW but not  
on off-screen pixmaps. I used the following changes to make it work:



diff -u -w -r1.1.1.3 xaaCpyArea.c
- --- xaaCpyArea.c  9 Jun 2001 15:09:02 -   1.1.1.3
+++ xaaCpyArea.c3 Mar 2008 20:51:05 -
@@ -64,9 +64,16 @@
   return (XAABitBlt( pSrcDrawable, pDstDrawable,
pGC, srcx, srcy, width, height, dstx, dsty,
XAADoBitBlt, 0L));
+   } else {
+   if(infoRec->ScreenToScreenBitBlt &&
+CHECK_ROP(pGC,infoRec->ScreenToScreenBitBltFlags) &&
+CHECK_ROPSRC(pGC,infoRec->ScreenToScreenBitBltFlags) &&
+CHECK_PLANEMASK(pGC,infoRec->ScreenToScreenBitBltFlags))
+return (XAABitBlt( pSrcDrawable, pDstDrawable,
+   pGC, srcx, srcy, width, height, dstx, dsty,
+   XAADoImageWrite, 0L));
}
   }


This does not look correct.  Shouldn't this be more in line with  
the case where the destination drawable is a window?  (i.e. test  
bitsPerPixel's and WritePixmap files instead of ScreenToScreenBitBlt).


The whole logic looks a little bit fishy, I used the first if()'s  
source-in-memory branch first but wasn't quite sure if that's doing  
the right thing, where it;s now looked better to me but I won't claim  
I completely understand XAA's inner voodoo. All I want is the make  
XAA use ImageWrite()s for all RAM-to-VRAM transfers if the driver  
supports it.
Otherwise, teaching the framebuffer layer to cope with a tiled  
framebuffer might be necessary in the long run, any pointers where to  
start?


have fun
Michael

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBR83OYspnzkX8Yg2nAQJNnAf/auo5d5PGw/M8IpvL+GIoCXL7ME2QGMsp
Wv6wSrZ9ONA+uFEI/ppUBF10gwdXulEMuXy6bVyqzTGzRDCl3xxmF2f0IVuo6MWX
/Ar+rg7wHJgnl94UUQnX6z02mBS3ldx/f9U534KqjmrUsnU8nx00AHe07hQRHBrE
m0gPaiO2/ueX5IXmtVS1S+TmV6tkQ2UKp+sZjflHEp7078kV9wQkC8A7ImkOPhxe
DBkRLt76uGR6YUlvivHAMxpdqBiIbxBLWpd1mg65/Cw48uJD850j3BoAGFZqDl+x
sPadDNC6yxY4/5c/Oq4vEo2Fcss87PdNQbow9YR9m9AEmsktK5DS5Q==
=hzKc
-END PGP SIGNATURE-
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: xaa vs. WriteImage()

[Michael Lorenz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

Otherwise, teaching the framebuffer layer to cope with a tiled  
framebuffer might be necessary in the long run, any pointers where  
to start?


By design, this is a driver issue, as it is responsible for  
providing VRAM access to the rest of the server.


Really. Now /that/ was helpful. Guess I'm on my own here.

have fun
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBR88QOspnzkX8Yg2nAQJvNQgApOyezj1wfcoiLcO/IpS6R9mdnQ7RdOHT
R08xjo5fueS512tBGgjnB8ay8vilEbaTRE94J45sLGhLueKtRd6nNjUseyz3rggt
v1xaHsaNQzTJIQ0BL5m27YN5bg3bk4e16EuekGeggdyBd/zDFHCWPNdm03Jy/ku4
ypxDlrF8OV+Wrf5hRnDP64iBT2KzOptIkg/UBiIk3fGbbxLJAryL03gozV35c6Zt
b9g5I30HNKzr4pnb0AfOZ08fdBLQW3J5CqnD1a5CDrCQJW/BmfR6MttbNKvaqTwk
63iY5Abey8VTtXG6gmdFkAjX/N4ArYnHsbS78TlrIFQ6NwE4+C4HRw==
=vrbT
-END PGP SIGNATURE-
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: xaa vs. WriteImage()

[Michael Lorenz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

On Mar 5, 2008, at 19:06, Alex Deucher wrote:

On Tue, Mar 4, 2008 at 5:34 PM, Michael Lorenz  
<[EMAIL PROTECTED]> wrote:

-BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hello,


On Mar 4, 2008, at 15:37, Marc Aurele La France wrote:


On Mon, 3 Mar 2008, Michael Lorenz wrote:


I noticed the following - XAACopyArea() only attempts to use
accelerated WriteImage() when writing to a DRAWABLE_WINDOW but not
on off-screen pixmaps. I used the following changes to make it  
work:



diff -u -w -r1.1.1.3 xaaCpyArea.c
- --- xaaCpyArea.c   9 Jun 2001 15:09:02 -   1.1.1.3
+++ xaaCpyArea.c 3 Mar 2008 20:51:05 -
@@ -64,9 +64,16 @@
   return (XAABitBlt( pSrcDrawable, pDstDrawable,
 pGC, srcx, srcy, width, height, dstx, dsty,
 XAADoBitBlt, 0L));
+} else {
+if(infoRec->ScreenToScreenBitBlt &&
+ CHECK_ROP(pGC,infoRec->ScreenToScreenBitBltFlags) &&
+ CHECK_ROPSRC(pGC,infoRec->ScreenToScreenBitBltFlags) &&
+ CHECK_PLANEMASK(pGC,infoRec->ScreenToScreenBitBltFlags))
+return (XAABitBlt( pSrcDrawable, pDstDrawable,
+pGC, srcx, srcy, width, height, dstx, dsty,
+XAADoImageWrite, 0L));
 }
   }


This does not look correct.  Shouldn't this be more in line with
the case where the destination drawable is a window?  (i.e. test
bitsPerPixel's and WritePixmap files instead of  
ScreenToScreenBitBlt).


 The whole logic looks a little bit fishy, I used the first if()'s
 source-in-memory branch first but wasn't quite sure if that's doing
 the right thing, where it;s now looked better to me but I won't  
claim

 I completely understand XAA's inner voodoo. All I want is the make
 XAA use ImageWrite()s for all RAM-to-VRAM transfers if the driver
 supports it.
 Otherwise, teaching the framebuffer layer to cope with a tiled
 framebuffer might be necessary in the long run, any pointers  
where to

 start?


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


Yeah, I'm dimly aware of these things - my problem is that the  
hardware in question doesn't give me a linear view on the framebuffer.
All I have is a small linear buffer I can use to DMA data in or out  
of the tiled framebuffer. The other problem is that the machine's  
native pixel format is RGBA, if I want 24bit colour that's the only  
one I can use. Fortunately the DMA engine can convert pixels on the  
fly so I can pretend it's ABGR. So pixels would have to be endian- 
flipped as well when the fb layer accesses VRAM - is there any prior  
art for that?
So far my driver supports image writes, screen-to-screen copies,  
rectangle fills, solid and dashed lines, colour expansion and alpha  
textures. ARGB textures should work as well but I couldn't find a  
user for those - nothing in xfce4 or windowmaker seems to do anything  
with that.
Another thing - I sprinkled xf86Msg()s all over XAA, sometimes  
XCopyArea() calls seem to end up writing to the framebuffer but not  
through xaaCopyArea() - any ideas?


have fun
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBR89I6cpnzkX8Yg2nAQIkHAgAribd+WTw/t5Xv5nunNUZn6hrwluv+e7J
ox9Hg9V/Yp2CVZVPgSc+3aJOjLPUTPg6L/4tVuNBQLSVnbMO2j7MdGLkhxGznGzl
iv5NNqqToXDO2MM9ctBo8dNB1o3RU76dnbs4QomHYqi/HpNmG+JLJLu3L1+uNjoC
cKjTsUEKWM/UgK+A2UMkjV9vpdEEYoYz2zRu6Njy3bfP7Jyoyh7mwl/c/kamWvU6
k8KnHcRalgsXjmhNRGSV4VOmpc3c/JubHROYTrG5T61aNVge1GAi2jLl27I99vhR
0Bv8iA6juJ5KxZpUajbHSL5vXAZk/QaXss1g7AuVSGCphqE3IC/kHA==
=wynV
-END PGP SIGNATURE-
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: xaa vs. WriteImage()

[Michael Lorenz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

On Mar 6, 2008, at 14:12, Alex Deucher wrote:

On Thu, Mar 6, 2008 at 2:00 PM, Michael Lorenz  
<[EMAIL PROTECTED]> wrote:

-BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hello,

 On Mar 5, 2008, at 19:06, Alex Deucher wrote:


On Tue, Mar 4, 2008 at 5:34 PM, Michael Lorenz
<[EMAIL PROTECTED]> wrote:

-BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hello,


On Mar 4, 2008, at 15:37, Marc Aurele La France wrote:


On Mon, 3 Mar 2008, Michael Lorenz wrote:


I noticed the following - XAACopyArea() only attempts to use
accelerated WriteImage() when writing to a DRAWABLE_WINDOW but  
not

on off-screen pixmaps. I used the following changes to make it
work:



diff -u -w -r1.1.1.3 xaaCpyArea.c
- --- xaaCpyArea.c   9 Jun 2001 15:09:02 -   1.1.1.3
+++ xaaCpyArea.c 3 Mar 2008 20:51:05 -
@@ -64,9 +64,16 @@
   return (XAABitBlt( pSrcDrawable, pDstDrawable,
 pGC, srcx, srcy, width, height, dstx, dsty,
 XAADoBitBlt, 0L));
+} else {
+if(infoRec->ScreenToScreenBitBlt &&
+ CHECK_ROP(pGC,infoRec->ScreenToScreenBitBltFlags) &&
+ CHECK_ROPSRC(pGC,infoRec->ScreenToScreenBitBltFlags) &&
+ CHECK_PLANEMASK(pGC,infoRec- 
>ScreenToScreenBitBltFlags))

+return (XAABitBlt( pSrcDrawable, pDstDrawable,
+pGC, srcx, srcy, width, height, dstx, dsty,
+XAADoImageWrite, 0L));
 }
   }


This does not look correct.  Shouldn't this be more in line with
the case where the destination drawable is a window?  (i.e. test
bitsPerPixel's and WritePixmap files instead of
ScreenToScreenBitBlt).


 The whole logic looks a little bit fishy, I used the first if()'s
 source-in-memory branch first but wasn't quite sure if that's  
doing

 the right thing, where it;s now looked better to me but I won't
claim
 I completely understand XAA's inner voodoo. All I want is the make
 XAA use ImageWrite()s for all RAM-to-VRAM transfers if the driver
 supports it.
 Otherwise, teaching the framebuffer layer to cope with a tiled
 framebuffer might be necessary in the long run, any pointers
where to
 start?


Several drivers (radeon, intel, savage) in the Xorg tree provide
support for various tiling methods.  Generally the chip provides a
surface control or aperture for exposing a tiled region to the  
CPU as

a linear surface.  For acceleration, you have to keep track of what
buffers are tiled in the driver and do the right thing with the
blitter when using those surfaces.


 Yeah, I'm dimly aware of these things - my problem is that the
 hardware in question doesn't give me a linear view on the  
framebuffer.

 All I have is a small linear buffer I can use to DMA data in or out
 of the tiled framebuffer. The other problem is that the machine's
 native pixel format is RGBA, if I want 24bit colour that's the only
 one I can use. Fortunately the DMA engine can convert pixels on the
 fly so I can pretend it's ABGR. So pixels would have to be endian-
 flipped as well when the fb layer accesses VRAM - is there any prior
 art for that?


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


I'll have a look at that - the main reason I'm using XFree86 is that  
it's already working on NetBSD/sgimips, Xorg needs some more work but  
I'll eventually do it.
Hmm, some drivers access video memory through tiny apertures like the  
VGA range - maybe I can do something like this - let the rest of the  
Xserver render into my DMA buffer and then blit it in place.


have fun
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBR9BM2cpnzkX8Yg2nAQK+dAf7B+5F0uHL8Vh0o7FCqWmdEHMs0EFT1eb1
4tvc/V8SVB2ZFnHBdkA5YdwXq6dIhNeQQRFDCu29VFBwlj4GHzkhAcYdkI00sDDa
84OpdxtuYTT0WvC74uaW486zMpEze0/0AvI3ZFeiP078TCUJ4161u8pA5zq6VkOu
FjaFBYcte/rGhNcg/VsBsDOx5gLwQxpEqImtFuqIRg9xgN2R1Zmto7BZvKV7eUvS
FRnvfZjBiTt/AbjdHtwwWEeRnp/3vu4cTz3+6pWmDMlVq4UFtLkvLVk8429Oz/eQ
tjv3MlU7cpeXLwFz3s3QqJ/4RYlmQGI7dDGYHDWT1yRLdAnDLVdafg==
=Biva
-END PGP SIGNATURE-
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: xaa vs. WriteImage()

[Michael Lorenz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

On Mar 6, 2008, at 15:58, Alex Deucher wrote:

On Thu, Mar 6, 2008 at 2:58 PM, Michael Lorenz  
<[EMAIL PROTECTED]> wrote:

-BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hello,

 On Mar 6, 2008, at 14:12, Alex Deucher wrote:


On Thu, Mar 6, 2008 at 2:00 PM, Michael Lorenz
<[EMAIL PROTECTED]> wrote:

-BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hello,

 On Mar 5, 2008, at 19:06, Alex Deucher wrote:


On Tue, Mar 4, 2008 at 5:34 PM, Michael Lorenz
<[EMAIL PROTECTED]> wrote:

-BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hello,


On Mar 4, 2008, at 15:37, Marc Aurele La France wrote:


On Mon, 3 Mar 2008, Michael Lorenz wrote:


I noticed the following - XAACopyArea() only attempts to use
accelerated WriteImage() when writing to a DRAWABLE_WINDOW but
not
on off-screen pixmaps. I used the following changes to make it
work:



diff -u -w -r1.1.1.3 xaaCpyArea.c
- --- xaaCpyArea.c   9 Jun 2001 15:09:02 -   1.1.1.3
+++ xaaCpyArea.c 3 Mar 2008 20:51:05 -
@@ -64,9 +64,16 @@
   return (XAABitBlt( pSrcDrawable, pDstDrawable,
 pGC, srcx, srcy, width, height, dstx, dsty,
 XAADoBitBlt, 0L));
+} else {
+if(infoRec->ScreenToScreenBitBlt &&
+ CHECK_ROP(pGC,infoRec->ScreenToScreenBitBltFlags) &&
+ CHECK_ROPSRC(pGC,infoRec- 
>ScreenToScreenBitBltFlags) &&

+ CHECK_PLANEMASK(pGC,infoRec-

ScreenToScreenBitBltFlags))

+return (XAABitBlt( pSrcDrawable, pDstDrawable,
+pGC, srcx, srcy, width, height, dstx, dsty,
+XAADoImageWrite, 0L));
 }
   }


This does not look correct.  Shouldn't this be more in line with
the case where the destination drawable is a window?  (i.e. test
bitsPerPixel's and WritePixmap files instead of
ScreenToScreenBitBlt).


 The whole logic looks a little bit fishy, I used the first if 
()'s

 source-in-memory branch first but wasn't quite sure if that's
doing
 the right thing, where it;s now looked better to me but I won't
claim
 I completely understand XAA's inner voodoo. All I want is the  
make
 XAA use ImageWrite()s for all RAM-to-VRAM transfers if the  
driver

 supports it.
 Otherwise, teaching the framebuffer layer to cope with a tiled
 framebuffer might be necessary in the long run, any pointers
where to
 start?


Several drivers (radeon, intel, savage) in the Xorg tree provide
support for various tiling methods.  Generally the chip provides a
surface control or aperture for exposing a tiled region to the
CPU as
a linear surface.  For acceleration, you have to keep track of  
what

buffers are tiled in the driver and do the right thing with the
blitter when using those surfaces.


 Yeah, I'm dimly aware of these things - my problem is that the
 hardware in question doesn't give me a linear view on the
framebuffer.
 All I have is a small linear buffer I can use to DMA data in or  
out

 of the tiled framebuffer. The other problem is that the machine's
 native pixel format is RGBA, if I want 24bit colour that's the  
only
 one I can use. Fortunately the DMA engine can convert pixels on  
the

 fly so I can pretend it's ABGR. So pixels would have to be endian-
 flipped as well when the fb layer accesses VRAM - is there any  
prior

 art for that?


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


 I'll have a look at that - the main reason I'm using XFree86 is that
 it's already working on NetBSD/sgimips, Xorg needs some more work  
but

 I'll eventually do it.
 Hmm, some drivers access video memory through tiny apertures like  
the

 VGA range - maybe I can do something like this - let the rest of the
 Xserver render into my DMA buffer and then blit it in place.


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


Wouldn't that interfere with XAA? If I could catch the framebuffer  
writes that bypass XAA that way that would solve my problem.

Thanks!

have fun
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBR9BhlspnzkX8Yg2nAQLzKwf9GfmbcQZVMLvhx6Je/CgU6fadr/VJq+AZ
sBetdsOeXhFQxGlUFouG8DrDalrSwccXnEo+S4/zuPd5RGn01XmTfm5MBEvxMDAV
upT1U8a5szyHN8t7MgpGwzVoG6Y21F9n07RHsIs/hXB0OfV9yXaM6J3enKRt84Kp
S0pGZWB5xfyrTqBwP8gn1JSq1uTvJr/2zWHE/bwWu8ShAvD2l87FRrsAy0zKfRY6
NWua4rpwDY+XLAsx/kxkmTWbHsKFie+OuO6RUIyqRV+Ix5auLXb7rDRg5S/rKZfx
n2dXmXDs4BZBcl6WzyxEMzthiS88UCQNYjbhGlcL6cwaWC8H5hja1Q==
=OF0s
-END PGP SIGNATURE-
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: xaa vs. WriteImage()

[Michael Lorenz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

On Mar 6, 2008, at 16:40, Alex Deucher wrote:

On Thu, Mar 6, 2008 at 4:26 PM, Michael Lorenz  
<[EMAIL PROTECTED]> wrote:

On Mar 6, 2008, at 15:58, Alex Deucher wrote:


On Thu, Mar 6, 2008 at 2:58 PM, Michael Lorenz
<[EMAIL PROTECTED]> wrote:

-BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hello,

 On Mar 6, 2008, at 14:12, Alex Deucher wrote:


On Thu, Mar 6, 2008 at 2:00 PM, Michael Lorenz
EXA has prepare/finish access hooks for CPU access to buffers.  I
don't think XAA has anything similar.  There's also an wrapable FB
module, although I think it's only available in Xorg.


 I'll have a look at that - the main reason I'm using XFree86 is  
that

 it's already working on NetBSD/sgimips, Xorg needs some more work
but
 I'll eventually do it.
 Hmm, some drivers access video memory through tiny apertures like
the
 VGA range - maybe I can do something like this - let the rest  
of the

 Xserver render into my DMA buffer and then blit it in place.


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


 Wouldn't that interfere with XAA? If I could catch the framebuffer
 writes that bypass XAA that way that would solve my problem.
 Thanks!


Yeah, you gotta pick one or the other IIRC.  However for most modern
desktops you either have to be entirely SW or entirely HW or
performance sucks.  You lose if any sort of fallbacks cause a pixmap
migration to/from vram.


In my case VRAM is RAM, and the CPU is pretty slow - I've had things  
running entirely SW and performance sucked. Not the slowest I've ever  
seen but nowhere near what the HW can do.
Also, many X applications have trouble with the HW's native pixel  
format, cairo for instance just crashes. Using the DMA engine I can  
pretend it's using something more common - ABGR - and those  
applications just work fine. I think the next thing I'll try is to  
pretend that we're accessing VRAM through a small window, there must  
be prior art for that somewhere in the source tree.


have fun
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBR9BtZcpnzkX8Yg2nAQJKvggAuAmc/lGnCFx4JYnvLKeE9uMyDBWIu48V
emxeNH3eIbH2U8kc4rthaQVtDfmcMK6rWHgk89shlZiUonZAjuCjl9alDERAPu3Z
By2y5PX/0KFfVq/PXr2YpuFpxQSUD8Av9Mn+ReouTA6usOABPSRVEfVjx5hsCbkq
7dYyLsAYkz9gBV3YzfmZn16ltOIfu2dzXXaTUGDkoL//jkj0pMDCptr2k5UvGzdm
R4FNvGImR3lf51HzMjx43qvkpWu2vvjdDZrOdZdZr4bxY0Wem2OzgmOtgGzACh8z
zNgsKVxRfJ8w2TzfUibeI16FanT+60nZuikJvBh/ZEfZaH+igcp8Cg==
=NHsm
-END PGP SIGNATURE-
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: xaa vs. WriteImage()

[Michael Lorenz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

On Mar 6, 2008, at 18:02, Alex Deucher wrote:

On Thu, Mar 6, 2008 at 5:17 PM, Michael Lorenz  
<[EMAIL PROTECTED]> wrote:

-BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hello,

 On Mar 6, 2008, at 16:40, Alex Deucher wrote:


On Thu, Mar 6, 2008 at 4:26 PM, Michael Lorenz
<[EMAIL PROTECTED]> wrote:

On Mar 6, 2008, at 15:58, Alex Deucher wrote:


On Thu, Mar 6, 2008 at 2:58 PM, Michael Lorenz
<[EMAIL PROTECTED]> wrote:

-BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hello,

 On Mar 6, 2008, at 14:12, Alex Deucher wrote:


On Thu, Mar 6, 2008 at 2:00 PM, Michael Lorenz
EXA has prepare/finish access hooks for CPU access to  
buffers.  I
don't think XAA has anything similar.  There's also an  
wrapable FB

module, although I think it's only available in Xorg.


 I'll have a look at that - the main reason I'm using XFree86 is
that
 it's already working on NetBSD/sgimips, Xorg needs some more  
work

but
 I'll eventually do it.
 Hmm, some drivers access video memory through tiny apertures  
like

the
 VGA range - maybe I can do something like this - let the rest
of the
 Xserver render into my DMA buffer and then blit it in place.


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


 Wouldn't that interfere with XAA? If I could catch the framebuffer
 writes that bypass XAA that way that would solve my problem.
 Thanks!


Yeah, you gotta pick one or the other IIRC.  However for most modern
desktops you either have to be entirely SW or entirely HW or
performance sucks.  You lose if any sort of fallbacks cause a pixmap
migration to/from vram.


 In my case VRAM is RAM, and the CPU is pretty slow - I've had things
 running entirely SW and performance sucked. Not the slowest I've  
ever

 seen but nowhere near what the HW can do.
 Also, many X applications have trouble with the HW's native pixel
 format, cairo for instance just crashes. Using the DMA engine I can
 pretend it's using something more common - ABGR - and those
 applications just work fine. I think the next thing I'll try is to
 pretend that we're accessing VRAM through a small window, there must
 be prior art for that somewhere in the source tree.



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


Yeah, that's the software-only case. Interesting but I'd rather find  
a way to make this work while being able to use the rendering engine.


have fun
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBR9B8FcpnzkX8Yg2nAQIe8Qf9FN2yZYRhGQv9f6B+ljBbkbIUx/8yXSe9
T9i4tMWGH5p1RnzoSU0GX8qHmmF8lm2ajMKI8yY496+Kma34NiPUN2QgrRJJrlen
yG2WOydYC1iqCYj+MA3pfJ3Nqns/xMJDj24BWVfpQGDDEHEaegjIcFpsXH5MW++W
dQbojEECbMFivSmTAuZ3u/YmfDskw6TqE+fTBGLLXurmnQY0lFok1IUeyS7dITuw
A5L2BJJMFjvP32uglb6LGUlw921Aj5o7kMEI7VBvJx8lgoTBPmT+lwXaacUbQ2iv
bG9+GFctpswI9nuI/CDNhvdKyMHlgUieYn9nHX90VQuGil02AvfpFw==
=t834
-END PGP SIGNATURE-
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: xaa vs. WriteImage()

[Michael Lorenz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

On Mar 7, 2008, at 13:03, Marc Aurele La France wrote:


On Wed, 5 Mar 2008, Michael Lorenz wrote:
Otherwise, teaching the framebuffer layer to cope with a tiled  
framebuffer might be necessary in the long run, any pointers  
where to start?


By design, this is a driver issue, as it is responsible for  
providing VRAM access to the rest of the server.



Really. Now /that/ was helpful. Guess I'm on my own here.


Not really.  This sounds like the kind of thing that is right up  
the mibank screen wrapper's alley, assuming the tiles are all the  
same size.


They are, always 64KB, depending on colour depth they're 512x128,  
256x128 or 128x128 pixels.


mibank can interoperate with any other screen wrapper (including  
XAA), except shadowfb, because the later is not a true screen wrapper.


An example of the use of mibank can be found in ATIPreInit() and  
ATIScreenInit().  Mine, that is;  not X.Org's lobotomised  
imitations of same.


That sounds like it's what I need, thanks!

have fun
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBR9GKRspnzkX8Yg2nAQK9fwf/bNN+ZV299AWKn2PFcLi67H82tH6JoSTd
Ykhwgnai7fw8iMhY9wPIK3nbYkWaEE88CdQ8ZzEyYVGcPix+XDydo+kbs5xSPvNr
+t+YHWabiyopbq3YjE1QXUzh6xNwknMRSuGo6iEzWSUhQfxpwzPNwXePZK7+PDdw
1OhKu9QpI8jxLqQOoH5BYTteK8leuVx15E+m1hXhIgFbrdnIgzF7bSnD5SkJwqou
QEnXXGY+A1Tx60RfrZssFDSA1+TnINKN55jJFRBWCC5DYRitFpRdXVqfyZdPU4dt
aW5qVAPk8NJl2/+Ck5tJrjvoBqo8dxl7MCGjBqkDRMFS/To2XKYBYQ==
=kP5V
-END PGP SIGNATURE-
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

IBM port replicator noise?

[Michael B Allen]

Does anyone have any insight into this problem? I can compile from
source if any has patches they want me to try out. The chip is the Radeon
Mobility 7000 IGP:

  http://www.ati.com/technology/hardware/mobilityradeon7000IGP/index.html

Thanks,
Mike

--original message to XFree86 list--
On Sat, 24 May 2003, Michael B Allen wrote:

I'm trying to get the external dvi-d output on my IBM T30 via port
replicator to work with my 1600x1200 flat panel. I tried X 4.2 but there
was a lot of garbage on the screen. So I upgraded to X 4.3 and it's
better but still there are red and green dots in gradient areas. I tried
to take a screenshot but it was clean. IBM's website has this to say:

  TP A30, A31, T30 - Maximum Digital Video (DVI) Resolution is 1280 x
  1024 at 60 Hz

  Symptom
  When attaching a Digital Flat Panel Display to the Digital Video
  Interactive (DVI) Connector on the back of the Dock or Port Replicator,
  running 1600 x 1200 resolution, video noise appears on the display.

  Affected configurations
  ThinkPad A30, A30p, A31, A31p and T30 computer systems external DVI
  Connector.

  Solution
  Use 1280 x 1024 or lower resolution with the DVI Display.

  Additional information
  DVI resolution higher than 1280x1024 is not supported on A30, A31,
  and T30 ThinkPads.

But this doesn't say explicitly that it's a hardware problem. The noise
isn't that bad. It's very very close but not quite. Any ideas?

Thanks,
Mike

-- 
A  program should be written to model the concepts of the task it
performs rather than the physical world or a process because this
maximizes  the  potential  for it to be applied to tasks that are
conceptually  similar and, more important, to tasks that have not
yet been conceived. 

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

Re: IBM port replicator noise?

[Michael B Allen]

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

So it's a hardware limitation? That's depressing and a little shocking. I
thought DVI was the future.

So I'm completely SOL. Returning the port replicator and getting the
docking station is a *lot* more money. It's so close to being usable.
Perhaps if I put ice cubes all over my laptop, .

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

Re: IBM port replicator noise?

[Michael B Allen]

> It is likely that the connector was only designed for 1280x1024 - which
> requires a smaller bandwidth. If the person with this problem is into
> hacking hardware he might try finding out which port replicator connector
> pins are used for DVI and whether the problem is interconnect within port
> replicator and/or interconnect within the notebook and/or noise from
> something else.
>
> I would also suggest trying to disconnect any other devices that might use
> port replicator connectors - especially USB ones.

Well my dad's a TV repair man.

Just kidding. Actually he is an EE and does a lot of DSP work (for which
I've written a driver once) so your comments do interest me. Are you
suggesting that the wires and connectors may just be too thin or made out
of the wrong material and that creating a new connector between the laptop
dock-out port to DVI-D in on the Monitor might be sufficient resolve the
problem? I was under the impression it was a chip-output problem but
that's pure speculation on my part. I wonder if I could even buy that male
connector let alone identify it.

PS: I found out the full-blown Docking Station II only supports
low-profile PCI cards so that's out. So I'm basically wasting a 1600x1200
flat-panel (unless things get better with a DVI-A cable maybe).

Can't win'em all I guess,
Mike
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Re: T30 and 2000FP

[Michael B Allen]

> Michael B Allen wrote:
>>>My concern is with the blurriness shown using D-Sub and 1600x1200
>>>resolution. It's no good. Are you seeing the same thing? or should I be
>>>wondering if the model I'm using is defective. I'll try it with another
>>>computer.
>>
>>
>> There's a very important setting on the 2000FP. I don't recall the name
>> of
>> it but it's "phase" or "shift" something. Open a work processor or
>> terminal with high contrast small font and play with this "phase"
>> setting.
>> It makes a BIG difference if you get it right. No matter what you do it
>> is
>> going to be a little blurry. Believe it or not the DVI spec doesn't
>> specify modes for resolutions that high. That's ultimately the problem.
>> But I've used the T30 with 2000FP for extended periods of time and it's
>> actually quite useable.
>>
>
> Thanks, I'll play around with it. On Windows XP, I was able to download
> Catalyst 3.4 from ATI, patched it for Mobility, and the DVI port now works
> at 1600x1200. It's a huge difference with the D-SUB output.  The challenge
> now is to find a driver that will allow DVI to work for XFree at this
> resolution.

That's big news! So the DVI out on a Thinkpad T30 with an ATI Radeon
Mobility 7500 AGP (LW) which has an advertised capability of only
1200x1024 will do [EMAIL PROTECTED] (with a Dell 2000FP 20" flat panel at
least) under XP with this Catalyst patch. I was VERY close under X but
there was a little noise. At least we know now the hardware and connectors
can handle it. Maybe we'll see that driver one day ...

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