Re: Does Red Hat Linux Phoebe beta support Intel 845 really?
Mete Kural wrote: XFree86 CVS is where Intel i845 support was first added. XFree86 CVS is what is in rawhide, and yes, in Red Hat Linux Phoebe beta. That's good news! So does Red Hat Linux Phoebe Beta really support Intel i845 then? I just want to make sure. In that case, I'll simply put 8.0 away and download Phoebe. Has anybody installed Phoebe and seen that the XFree86 version that comes with it includes the updated drivers? No, but it is the 4.3 pre-release. Not installing it on Debian... -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Does Red Hat Linux Phoebe beta support Intel 845 really?
> XFree86 CVS is where Intel i845 support was first > added. XFree86 > CVS is what is in rawhide, and yes, in Red Hat Linux > Phoebe beta. That's good news! So does Red Hat Linux Phoebe Beta really support Intel i845 then? I just want to make sure. In that case, I'll simply put 8.0 away and download Phoebe. Has anybody installed Phoebe and seen that the XFree86 version that comes with it includes the updated drivers? Thanks, Mete ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 Installation Problem
On Mon, 10 Feb 2003, Bryan W. Headley wrote: >> First of all, I suggest you talk to RedHat for support on stuff specific to >> their distro, which is lots in your case. >> > >Heh heh heh. And the first thing they'll say is, "you overwrote what >with what?!?" This will teach you, "building code with rpm is good"; >just open the .spec file, change the name of the tarball, figure out >which patches still need to be applied, and give it a rip! Or try the >version that's with Phoebe... XFree86 CVS is where Intel i845 support was first added. XFree86 CVS is what is in rawhide, and yes, in Red Hat Linux Phoebe beta. If you do not purchase unsupported hardware in the first place however, then you will not encounter support problems finding out it is unsupported hardware, and you wont have to use beta code to get things working (assuming that beta code actually supports the particular previously unsupported hardware) >> You will probably need to create a correct config file using RedHats config >> utility (no idea how that works). > >Used to be Xconfigurator in 7.x. Cursory look at 8.x tells me they're >running "XFree86 -configure". I recall that a previous version of >anaconda allowed X reconfigures after installation. It's been awhile, so >I forget how to do it. No, it's "redhat-config-xfree86", and is documented in our RELEASE-NOTES as well. >> I don't know if RedHat also uses '2' > >Level 3, I thought. Yes. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 Installation Problem
On Mon, 10 Feb 2003, Thomas Zander wrote: >> We bought a brand new PC and installed Red Hat 8.0 on >> it. The video card didn't work because there are no >> drivers for the on-board Intel 845 video card in the >> version of XFree86 shipped with Red Hat 8.0. On >> Intel's website it was recomended to download the >> latest CVS snapshot of XFree86. So I downloaded all of >> the binaries for the latest CVS snapshot of XFree86, >> which is 4.2.99.901. I installed all of the packages >> in that snapshot and overwrote my old configuration >> files. >> >> Now when I restart the computer, it goes into the X >> window environment but the message dialog box in the >> lower right corner keeps on printing "console log >> localhost.localdomain" over and over again and doesn't >> do anything else. The mouse stays as a sandbox and the >> system doesn't respond to anything. >> >> Do you have any suggestions what I may have done >> wrong? Should I not have overwritten the old >> configuration files? Why does the message box keep on >> printing console log localhost.localdomain over and >> over? >> >> I would greatly appreciate any help. > >First of all, I suggest you talk to RedHat for support on stuff specific to >their distro, which is lots in your case. [SNIP] >After rebooting you can login and configure your graphics card as usual. No, this is not a Red Hat support issue at all. XFree86 4.2.0 and 4.2.1 do not support the Intel i845 graphics chipsets at all, and as such, Red Hat Linux 8.0, which ships XFree86 4.2.0, does not support the Intel i845 graphics chipsets at all. This has to be about the number one question to be asked on both mailing lists nowadays. It's asked at least once, if not 35 times per day almost every day. I'm amazed that nobody thinks of searching the web first, or searching mailing list archives, or heck, why not look directly at the XFree86 4.2.0 release notes and support information found on the XFree86 website: http://www.xfree86.org/4.2.0/Status17.html#17 http://www.xfree86.org/4.2.1/Status17.html#17 You see - unsupported. Not a Red Hat problem. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Tablet driver for Aiptek HyperPen USB
On Mon, 10 Feb 2003, Bryan W. Headley wrote: >> So, one more vote for answers ;) >> Thanx. > >I say let's set up a chat channel somewhere, and line up other input >device champions, and we can spend 30 minutes or so asking stupid >questions until everyone feels comfortable with each other. > >Do we have a volunteer to ask/answer dumb questions from we newbies? #xfree86-devel on irc.freenode.net is always open to the public for XFree86 developmental discussions. Feel free to join in anytime if you like. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: repeated X restarts with i810 not freeing sys resources?
> On Saturday 08 February 2003 05:41 pm, David Dawes wrote: > > On Sat, Feb 08, 2003 at 01:07:25PM -0700, patrick charles wrote: > > >How would I communicate this? Somebody on XFree86 working with or have > > > contact with the appropriate people in kernel/agpgart development? > > > > First of all, how are you "killing" the X server? I haven't seen this > > behaviour when the X server exits normally, and I've done a lot of > > testing where 32MB is allocated per run on machines with only 128MB of > > physical memory. > > > > There are people here familiar with the kernel agpgart driver. > > > > Note that just because top shows that there's little memory free doesn't > > mean that the agpgart driver isn't freeing it. Also the agpgart driver > > allocates physical pages, never swap. I'm not sure what the symptoms > > are when it can't get any free physical pages. On my test system the > > free memory indicated by top does go up when the X server exits, and > > this is on an otherwise idle system. > > > > So, I'd suggest starting a bare X server (run just 'X') on an otherwise > > idle system, see what top reports, then exit it cleanly > > (), and see if the free memory amount changes. > > Check the X server log to confirm how much memory was allocated via the > > agpgart mechanism (look for the lines containing "Allocated"). > > > > If that looks OK, then try the same thing you tried before but with a > > bare X server and an idle system. > > > > David David, I ran some tests as you suggested. I started up a bare X server using the command 'X' on an idle system. I then exited cleanly using ctrl-alt-bak. I recorded the amount of physical RAM free before and after the X start. I repeated this process. After 13 iterations, the machine became very sluggish. After 16 iterations, the machine hung. Still looks like X (or, the agpgart driver?) is not freeing resources. The machine gradually ran out of physical RAM. Let me know if I can provide any more information, XFree86 logs, or? Details attached. thanks, -pat [ 0] after fresh boot w/ no X running: 84,516K free [ 1] after running 'X': 56,472K free [ 1] after ctrl-alt-bak: 68,796K free [ 2] after running 'X': 48,104K free [ 2] after ctrl-alt-bak: 60,656K free [ 3] after running 'X': 40,716K free [ 3] after ctrl-alt-bak: 53,272K free [ 4] after running 'X': 33,228K free [ 4] after ctrl-alt-bak: 45,784K free [ 5] after running 'X': 25,888K free [ 5] after ctrl-alt-bak: 38,472K free [ 6] after running 'X': 18,572K free [ 6] after ctrl-alt-bak: 31,116K free [ 7] after running 'X': 11,372K free [ 7] after ctrl-alt-bak: 23,672K free [ 8] after running 'X': 4,096K free [ 8] after ctrl-alt-bak: 16,344K free [ 9] after running 'X': 1,060K free [ 9] after ctrl-alt-bak: 13,856K free [10] after running 'X': 1,180K free [10] after ctrl-alt-bak: 13,640K free [11] after running 'X': 952K free [11] after ctrl-alt-bak: 13,400K free [12] after running 'X': 984K free [12] after ctrl-alt-bak: 13,400K free [13] after running 'X': 948K free [13] after ctrl-alt-bak: 13,400K free [14] after running 'X': 948K free [14] after ctrl-alt-bak: 10,000K free [15] after running 'X': 944K free [15] after ctrl-alt-bak: 5,704K free [16] after running 'X': [machine hung] [16] After iteration #9, the machine started showing disk swap in use: [ 9]436K swap used [10]636K swap used [11] 1,088K swap used [12] 4,532K swap used [13] 8,444K swap used [14] 12,088K swap used [15] 12,492K swap used After iteration #13, the machine starts to behave sluggishly, both at the command-line and when painting/moving the cross-hair cursor on the bare X desktop. Presumably because components of the core o/s are being swapped in and out of RAM? After 16 iterations, X hung on startup, the cross-hair cursor didn't appear. All your base are belong to us. I couldn't stop X and got no response when trying to remotely ssh to the machine. System is a Dell GX60 with integrated intel extreme graphics XFree86 Version 4.2.99.901 (4.3.0 RC 1) Driver is i810 Kernel is 2.4.20-2.36 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Crazy radeon problem
Hi all, I've just recently subscribed and never posted, so I'll give a quick introduction of myself. I work for Terra Soft Solutions and am the lead developer of Yellow Dog Linux. This is a rpm-based Linux distro for PowerPC microprocessors. We tend to track Red Hat fairly closely and our main hardware platform is Apple machines. I apologize in advanced for the long-winded nature of this message. For the last several months we've been tracking XFree86 4.3 development and I've been using a Apple Power Mac with Radeon 7500 as my primary workstation. Recently, I got DRI working on this machine based upon Mike Harris' 4.2.99.4 packages in Red Hat's Rawhide. I got very good performance but did find some problems. Of note, every time I changed to a virtual console and then switched back to X, the video hardware locked up, forcing a reboot (or power down). This is DRI related.. as I can change consoles just fine using 'fbdev'. I was able to reproduce this several times and reported it to Michel Dänzer. However, on the last time it happened, after rebooting when I started X, I obtained the following strange artifacts: http://stage.terraplex.com/~dburcaw/radeon.jpg Note that the X server does not crash, but the system becomes unusable at the console. Even switching back to the virtual consoles yields a very similar display. Now, after a while of using console and 'fbdev', I decided to try again... instead of the artifacts above (which happened consistently even after reboots), the X server crashes with: (II) Loading sub module "radeon" (II) LoadModule: "radeon" (II) Reloading /usr/X11R6/lib/modules/drivers/radeon_drv.o (II) resource ranges after probing: [0] -1 0 0x - 0x (0x1) MX[B] [1] -1 0 0x - 0x (0x1) MX[B] [2] -1 0 0xf520 - 0xf53f (0x20) MX[B] [3] -1 0 0x80081000 - 0x80081fff (0x1000) MX[B] [4] -1 0 0x80082000 - 0x80082fff (0x1000) MX[B] [5] -1 0 0x8000 - 0x8007 (0x8) MX[B] [6] -1 0 0x9002 - 0x9003 (0x2) MX[B](B) [7] -1 0 0x9000 - 0x9000 (0x1) MX[B](B) [8] -1 0 0x9800 - 0x9fff (0x800) MX[B](B) [9] -1 0 0x8008 - 0x8008007f (0x80) MX[B] [10] 0 0 0x000a - 0x000a (0x1) MS[B] [11] 0 0 0x000b - 0x000b7fff (0x8000) MS[B] [12] 0 0 0x000b8000 - 0x000b (0x8000) MS[B] [13] -1 0 0x - 0x (0x1) IX[B] [14] -1 0 0x - 0x (0x1) IX[B] [15] -1 0 0x0400 - 0x04ff (0x100) IX[B](B) [16] -1 0 0x0400 - 0x047f (0x80) IX[B] [17] 0 0 0x03b0 - 0x03bb (0xc) IS[B] [18] 0 0 0x03c0 - 0x03df (0x20) IS[B] (II) Setting vga for screen 0. (II) Loading sub module "vgahw" (II) LoadModule: "vgahw" (II) Loading /usr/X11R6/lib/modules/libvgahw.a (II) Module vgahw: vendor="The XFree86 Project" compiled for 4.2.99.901, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.6 (II) RADEON(0): vgaHWGetIOBase: hwp->IOBase is 0x03b0, hwp->PIOOffset is 0x (II) RADEON(0): PCI bus 0 card 16 func 0 (II) RADEON(0): here 0 (II) UnloadModule: "ati" (II) UnloadModule: "vgahw" (II) Unloading /usr/X11R6/lib/modules/libvgahw.a (II) UnloadModule: "radeon" (EE) Screen(s) found, but none have a usable configuration. Fatal server error: no screens found You will note that I am now running 4.2.99.901, and 'radeon' still doesn't work. After the artifacts went away, the above logging also occurred with 4.2.99.4. I have managed to debug things a bit and found that radeon_drv.o is failing due to this condition being met in radeon_driver.c: if (xf86RegisterResources(info->pEnt->index, 0, ResExclusive)) goto fail; (in function Bool RADEONPreInit()) Compiling with DEBUG=1, yields some interesting (but foreign to me) messages from xf86RegisterResources(): (II) Failed Resources after driver initialization for Entity: 0 [0] 0 0 0x0400 - 0x04ff (0x100) I So, in summary, I have no idea what is going on. X internals are a bit over my head at this point. This seems to have been triggered by a DRI-related hardware lock, but please also note that the above (current state of things) happens with 'radeon' even when DRI is not being loaded! I would appreciate any ideas that you all might have as to what the problem may be or where to go next in debugging this. Regards, Dan Burcaw [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: about change 614. Restore the Alt/Meta mappings for pc104/pc105...
On 7 Feb 2003, Jens Petersen wrote: >[Feel free to cc me since I'm not currently subscribed to the list.] > >Hello, > >I would like to ask why the following change was made to the >pc symbols file. Why should we rather have Super on Win >keys in 4.3, than Meta as in 4.2? Additionally xkb doesn't >seem to want to have both Alt and Meta on the some modifier >currently afaict. > >Thanks for any light on the matter, One word: consistency When $JOE_USER goes to one computer, and presses the key labelled "foo", he expects to have it respond with action "bar". When he goes to a different computer with a keyboard with a few extra keys, and he presses the key labelled "foo", he expects the key to respond with action "bar" as well. Having a frequently used keypress like "Meta" be one key on one keyboard, and some other key on a very similar keyboard that just has a few extra bonus keys, is not only insane, it is a technical support nightmare. I don't think anyone would want to be working telephone helpdesk support if Meta was to be a different key on 4 different keyboards. ;o) There are people out there who prefer the Meta key to not be the same as the Alt key, however I believe those people are also technically competant enough to configure XFree86 to remap the key to be the Windows key or whatever else they choose much easier than $JOE_USER can remap Meta to be Alt, where the majority of people are going to expect it. It's just a case of making the defaults sane for the average user. This is the same behaviour as under 4.2.x -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] i810 driver agpgart error
Michael Cardenas writes:
> Unfortunately, I edited i810_memory.c and changed
>
> if (xf86AgpGARTSupported() && !pI810->directRenderingEnabled
>&& pI810->GttBound) {
>
> to
>
> if (xf86AgpGARTSupported() && pI810->GttBound) {
>
> and it still produces the same error when I launch a second X server.
>
> (WW) xf86AcquireGART: AGPIOC_ACQUIRE failed (Device or resource busy)
> (EE) GARTInit: AGPIOC_INFO failed (Invalid argument)
> (EE) I810(0): AGP GART support is not available. Make sure your kernel has
> agpgart support or that the agpgart kernel module is loaded.
>
> Any suggestions on how to proceed?
>
This is not so easy to fix.
Only when used *without* DRI I810UnbindGARTMemory()
unbinds the GART memory. In this case unbinding
works well, starting a second server is no problem.
With DRI unbinding has to be done thru a different
interface. In this case the drm functions drmAgpUnbind(),
drmAgpRelease(), drmAcquire() and drmBind() need to take
care of unbinding/releaseing and reacquiring/rebinding
the AGP memory.
The current driver contains no code doing this.
The patch in attachment 1 fixes this. There is one
bug in the agpgart module and another one in agp_unbind()
in the drm kernel driver which prevent a VT switch when
direct rendering is enabled. Attachment 2 has patches.
One last problem remains:
These patches don't help starting a second Xserver:
This second Xserver hangs in the lock created by the first
one.
The release() in the drm kernel driver tries to obtain a
lock, when __HAVE_RELEASE is set. This lock is however held
by the first Xsever.
Only the i810 and i830 drivers have __HAVE_RELEASE set
therefore other Xservers aren't affected.
I've added Keith Whitwell, the original author of the i810 driver,
to Cc. Maybe he can help me to find out how to fix this.
Egbert.
diff.i810_vtswitch
Description: Binary data
diff.i810_vtswitch_kernel
Description: Binary data
[PATCH] xauth writes incomplete .xauth file and deletes old one whendisk full
The attached patch fixes a bug where xauth may write an
incomplete .xauth file and delete the old one if there is
insufficient disk space. The patch applies cleanly to CVS head,
xf-4_2-branch, and xf-4_1-branch and is tested.
Please credit: Harald Hoyer <[EMAIL PROTECTED]>
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
--- xc/programs/xauth/process.c.xauth-diskfull 2003-02-11 06:52:26.0 -0500
+++ xc/programs/xauth/process.c 2003-02-11 06:55:02.0 -0500
@@ -809,14 +809,20 @@
if (list->auth->name_length == 18
&& strncmp(list->auth->name, "MIT-MAGIC-COOKIE-1", 18) == 0)
{
- XauWriteAuth (fp, list->auth);
+ if(!XauWriteAuth (fp, list->auth)) {
+ (void) fclose (fp);
+ return -1;
+ }
}
}
for (list = xauth_head; list; list = list->next) {
if (list->auth->name_length != 18
|| strncmp(list->auth->name, "MIT-MAGIC-COOKIE-1", 18) != 0)
{
- XauWriteAuth (fp, list->auth);
+ if(!XauWriteAuth (fp, list->auth)) {
+ (void) fclose (fp);
+ return -1;
+ }
}
}
Re: Endianity problems in XFree86-4 XAA on MipsEB
I wrote two simple programms which do XFillRectangle's. The first one do it with a stipple and the second with a tile. I also built 2 X servers, the first one for BE machine, and the second one for LE. Now I can run my programs remotely and debug both X servers. And I told you already, that bytes on BE X in the tile case are swaped. If you'd like, I can send you my programs, and you could see the differencies in images on screen in BE case, if your driver uses XAA. Moreover, it looks like there is an error with endianity in stipples too. In the BE X, the XAACheckStippleReducibility() function get already "bit swapped" data in (CARD32*)pPixmap->devPrivate.ptr and then do one more bit swapping if the BIT_ORDER_IN_BYTE_MSBFIRST flag is set by a driver. I gues that (CARD32*)pPixmap->devPrivate.ptr must contain endianity independent data, but it looks like somebody swaped it before because the MSBFIRST flag is defined for Big Endian architecture. I found this bug with gdb support. In the "tile" case all is OK. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Tablet driver for Aiptek HyperPen USB
Zephaniah E. Hull wrote: On Mon, Feb 10, 2003 at 01:10:00PM -0600, Bryan W. Headley wrote: Really, tying in to hotplug, I'd like to know that a tablet's been attached, and if so, to which device entry in /dev/input... And that, means that you want to tie into my evdev input patches, http://people.debian.org/~warp/evdev/, read the readme. The 030_lnx_evdev.diff patch is the main one you want, look at the other two to see how to tie into it. So, one more vote for answers ;) Thanx. I say let's set up a chat channel somewhere, and line up other input device champions, and we can spend 30 minutes or so asking stupid questions until everyone feels comfortable with each other. Do we have a volunteer to ask/answer dumb questions from we newbies? Sounds like a good idea, get some X input people and let me know when and where. No volunteers so far, which means we're in charge :-) First thing we do, we rewrite everything in Forth...! I take it Greg and Vojtech have seen evdev? -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: getting ATI's IGP320M/IPG340M supported (more than just vesa)
Hi! I've just read the posting about ATI's IGP cards and would like to contribute as a tester if any drivers would be developed. I'm affraid I'm not able to help with the development (never wrote anything for XFree). But I have some C programming and debugging skills, so... If anyone is going to write the drivers and needs someone for testing, just let me know (email is below). BTW: I've got a Compaq notebook (Evo N1020v) with the IGP 340M. Regards! Filip Stanek +---+ | Filip Stanek VSB-TU Ostrava | | SGI administration | | e-mail: [EMAIL PROTECTED] | +---+ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Missing "lr_angle" mouse cursor in redglass theme ...
Hi The "lr_angle" mouse cursor is missing in redglass mouse cursor theme. You can verify this with blackbox windowmanager. Anyone who can fix this quickly? I'm not familiar at all neither with creating mouse cursors nor with using GIMP. :-( Best regards, Stefan Public Key available Stefan Dirsch (Res. & Dev.) SuSE Linux AG Tel: 0911-740530 Deutschherrnstr. 15-19 FAX: +49 911 741 77 55D-90429 Nuernberg http://www.suse.deGermany ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Tablet driver for Aiptek HyperPen USB
Thomas Zander wrote: ! I am looking for a way to do timers in the driver... Saw this in acecad, #define milisleep(ms) xf86usleep(ms*1000) To specify (in my case);is there a way to communicate with the driver from outside of X and set variables without restarting X ? Yeah, there's a way. I'm a little ashamed for thinking of it, but... you can specify several inputdevices to a single driver. (Sort of like how the wacom driver accepts a stylus, a cursor and an eraser device). One of these "devices" could read from a different device entry than the others. Say, a named pipe. X will set up the select() / read callbacks, and you can therefore read a stream for unknown purposes and reconfigure the rest of the driver, as appropriate. Problem that I see is that if any of your variables calls for a non-trivial change (such as a change in one of the AxisStruct's, or somebody hotplugged the input device in, and you have to reassociate the device to a new file handle), you need something less kludgish than this, that works at a higher level of abstraction than the Xinput driver. -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Endianity problems in XFree86-4 XAA on MipsEB
Mark Vojkovich wrote: I don't see any problems with that code. There are plenty of other drivers using it without problems. Perhaps you need to set the Mono8x8PatternFillFlags. Specifically (from the XAA.HOWTO): BIT_ORDER_IN_BYTE_MSBFIRST BIT_ORDER_IN_BYTE_LSBFIRST As with other color expansion routines this indicates whether the most or the least significant bit in each byte from the pattern is the leftmost on the screen. Default is always LSBFIRST because most PC hardware is that way. Perhaps you actually want MSBFIRST. There is no problem in bit ordering, but the problem is in byte ordring. In stipple case there is right ordering (as i see), and in tile case bytes are swapped. Driver can't distinguish stipple or tile case because it accept bitmasks in both cases. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Endianity problems in XFree86-4 XAA on MipsEB
Michel Dänzer wrote:
Yes of course, but In the first case the __most__ significant byte of
the bits[0] contains data and in the second case the __last__ significant
byte of the bits[0] contains data. So, you obtain swapped pattern0 and
pattern1 in the "tile" case.
I see where you're getting at, but does bits[0] really have the same
meaning in both cases?
Yes, I think so.
Let's assume that:
1. bpp = 8, pPixmap->drawable.width = pPixmap->drawable.height = 8;
2. our tile can be reduced to __mono__ 8x8 pattern.
1. stipple case
XAACheckStippleReducibility(PixmapPtr pPixmap)
{
...
CARD32 *IntPtr = (CARD32*)pPixmap->devPrivate.ptr;
CARD32 bits[8];
...
/* for our case i = 8*/
while(i--)
bits[i] = IntPtr[i] & mask; /* where mask = 0xFF00 */
break;
...
}
intPtr[0] contains valid data in the most significant byte for BE
machines, so you
need 0xFF00 mask to get vaild data from intPtr[0] and put it to
bits[0]. So, the MSB of bits[0] contains first string bitmask of 8x8
pattern.
And I guess there is no any endianity problems here.
2. tile case
XAACheckTileReducibility(PixmapPtr pPixmap, Bool checkMono)
{
CARD32 *IntPtr;
...
if(checkMono) {
...
if(pPixmap->drawable.bitsPerPixel == 8) {
/* this is our case */
unsigned char *srcp = pPixmap->devPrivate.ptr;
...
/* i = j = 8 for our case */
for(y = 0; y < i; y++) {
bits[y] = 0;
for(x = 0; x < j; x++) {
if(srcp[x] != fg) {
/* return if there is more then to colors in tile */
if(bg == -1) bg = srcp[x];
else if(bg != srcp[x]) return TRUE;
} else bits[y] |= 1 << x;
}
srcp += pitch;
}
...
In this case bits[0] also contains the first string of 8x8 pattern
(as I understand), but in the last significant byte (bits[0] & 0x00FF).
... but maybe there is a problem in code were pPixmap->devPrivate.ptr
is filled.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
