More sdk stuff
Is there any documentation other than reading Imake to figure out what gets included in the sdk...I am working on autotooling some of X, and maybe I would like to know how this sdk is currently constructed. Warren Turkal -- President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Warning related to SOCKLEN_TYPE in Xserver/os/xdmcp.c
David Dawes wrote (in a message from Monday 8) When building on FreeBSD 4.4 I'm getting the following warnings: The sa_len and sin_len fields are defined on this platform as u_char, while SOCKLEN_TYPE is defined as unsigned int. This looks like a potential problem given that the (u_char *) is dereferenced and written to as an (unsigned int *). oops, yes. What types to other BSD44SOCKETS platforms use for the sa_len and sin_len fields? They are both unsigned chars on Darwin, NetBSD and OpenBSD too. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: ansifying
Warren Turkal wrote (in a message from Tuesday 9)
When ansifying from KR code, which order should the arguments come in?
KR code:
int
blah(x, y)
float y;
int x;
{ ... }
Does the KR code go to (1) or (2)?
(1)
int
blah(int x, float y)
{ ... }
(2)
int
blah(float y, int x)
{ ... }
I am guessing that (1) is the correct answer.
Yes. And this is a trap doing conversions semi-automatically. One need
to be careful.
Also, can you have KR and ansi function definitions in the same file?
Yes, you can. But if you are converting existing code to ANSI
prototypes, try to be complete :)
Matthieu
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: ansifying
On Tue, 9 Sep 2003, Matthieu Herrb wrote: Yes. And this is a trap doing conversions semi-automatically. One need to be careful. That sort of thing is usually caught by compiler warnings. One that isn't is changing the type, e.g., int foo(x, y) char x; int y; int foo(char x, int y); /* incorrect */ int foo(int x, int x); /* correct */ I have some notes here: http://dickey.his.com/ansification/index.html Also, can you have KR and ansi function definitions in the same file? Yes, you can. But if you are converting existing code to ANSI prototypes, try to be complete :) Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: i855 and 1400x1050
Thomas Winischhofer writes: So, why is 1024x600 sorted out on this machine then? (I ask because SiS BIOSes sometimes list wrong modes when probing, and refer to wrong internal modes numbers. I had hoped that Intel folks just forgot to change their probe function for this very machine and report 1024x600 instead of 1400x1050.) 1024x600 is a very unusual mode (I know of only one machine using it), what's the point in supporting this mode on a machine with a 1400x1050 panel?! That 1024x600 is listed desn't mean it's supported. You have to look for a '*' in front of the mode name. However it's strange that this funny mode is known to the BIOS however not 1400x1050. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: ansifying xwininfo.c
Warren Turkal wrote: Here is a patch ansifying xwininfo.c. I diffed the executable after the changes to the executable from before the changes, and they were the same. I have opened a bug report at http://bugzilla.xfree86.org/show_bug.cgi?id=677 Warren Turkal -- President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: ansifying
On Tue, 9 Sep 2003, Derek Fawcus wrote:
On Tue, Sep 09, 2003 at 01:24:41AM -0500, Warren Turkal wrote:
Does the KR code go to (1) or (2)?
(1)
int
blah(int x, float y)
{ ... }
Hmm, given the KR promotion rules, shouldn't the above be converted
to:
int
blah(int x, double y)
{ ... }
( yes ;-)
unless you can be sure that there is no code relying upon the fact that
a float argument to this fn is converted to double at invokation?
i.e. initially try and preserve the same stack frame.
if you don't, interfaces change - which is undesirable.
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: i855 and 1400x1050
Thomas Winischhofer wrote: Alessandro Temil wrote: Egbert Eich wrote: David Here you are, i attached both i810 and vesa driver XFree86.0.log. (by the way, i'm new of this mailing list, if it doesn't allow messages with attachments i'll repost them inlined asap.) This moring i wrote to intel asking for the specifications, i hope to get a reply soon. Neither the VESA nor the i8xx driver lists any 1400x1050 mode. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel I know, that's why we need to program directly the video chip, as the windows driver does. Seems so. I found no trace of a 1400x1050 mode in the BIOS. However, it seems to support different panel types (brands, models) of that very resolution. If the reason for not implementing a mode for the native resolution in the BIOS is that the chip can be connected to many different video bridges, this is simply dumb. That way they need a huge windows driver, taking care of all that, which furthermore needs to be updated permanently if a new machine comes out... SiS folks haven't updated their Windows driver since February, and it works with about every machine in existance (due to the BIOS of all machines containing info on all supported modes for their host machine) A register dump from a windows driver would be the only way, I guess... Thomas Do you have any suggestion for what program/debugger/whatelse to use to get this dump? Alessandro ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: ansifying xwininfo.c
On Tue, 9 Sep 2003, Warren Turkal wrote: Thomas Dickey wrote: while I'm perfectly aware that extern is redundant, there are two things to be said in favor of keeping it: a) it's easy to grep for sure b) some compilers silently ignore conflicts with a static definition of the prototype, but can be persuaded to warn if the extern is explicit. (gcc does this, making it unsuitable as the only compiler to use for testing). also - extern prototypes really should be moved to a header file, otherwise they're not effective at flagging mismatches between different files.. All of the extern functions were defined in the file. These appear to be functions only useful to xwininfo. Why make a header for a one *.c program? I was offering general advice - most of the files in the X tree have a' mixture of extern/static prototypes. If a function's not used outside a given file, there's no reason to mark it extern... -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: X for a cramped PC environment
HS 1. anyone has been experimenting with X that's almost so tiny as HS tinyX, and liked what they got? TinyX is full X11, so your question really doesn't make sense. HS Well, it doesn't read a config file, Right, you meant XFree86 where you wrote X. HS and the result is that I can't seem HS to tell it to try several obvious places for a mouse, and use any of HS them. Look at linux/mouse.c, around line 890. HS I also can't whip up some sort of trivial mouse setup and tell HS it which of a pile of mice drivers to try It will automatically try all supported mouse protocols. In XFree86 4.3, the TTF rasteriser also does Type 1 by default. In 4.4, it will also do BDF and PCF. HS Urg. Thanks for the warning. I'm trying to chop a lot of size out HS by getting rid of all but one rendering mode. Look at lib/font/FreeType/ftmodule.h and comment out any modules you don't need. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: ansifying xwininfo.c
Thomas Dickey wrote (in a message from Tuesday 9) On Tue, 9 Sep 2003, Warren Turkal wrote: -#if NeedFunctionPrototypes -extern void scale_init(void); -extern char *nscale(int, int, int, char *); while I'm perfectly aware that extern is redundant, there are two things to be said in favor of keeping it: a) it's easy to grep for b) some compilers silently ignore conflicts with a static definition of the prototype, but can be persuaded to warn if the extern is explicit. (gcc does this, making it unsuitable as the only compiler to use for testing). ... and a 3rd reason is that 'extern' is not optional for variables. Most traditional Unix linkers will allow the same variable to be declared without 'extern' in multiple object files and merge them into only one, but this behaviour is not a feature one should rely on. And it fact, at least the Darwin linker treats this as an error. Doing the same for functions is more consistent. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: ansifying xwininfo.c
On Tue, 9 Sep 2003, Matthieu Herrb wrote: ... and a 3rd reason is that 'extern' is not optional for variables. Most traditional Unix linkers will allow the same variable to be declared without 'extern' in multiple object files and merge them into only one, but this behaviour is not a feature one should rely on. And it fact, at least the Darwin linker treats this as an error. true - most do, though the nicer ones warn about it (IRIX64 and Tru64, iirc). I've been burned occasionally by code that relies on the common linkage, and have used one of gcc's options to warn about it (-Xlink -warn-common). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: ansifying xwininfo.c
On Tue, 9 Sep 2003 21:57:23 +0200, Matthieu Herrb wrote:
Thomas Dickey wrote (in a message from Tuesday 9)
On Tue, 9 Sep 2003, Warren Turkal wrote:
-#if NeedFunctionPrototypes
-extern void scale_init(void);
-extern char *nscale(int, int, int, char *);
while I'm perfectly aware that extern is redundant, there are two
things to be said in favor of keeping it:
a) it's easy to grep for
b) some compilers silently ignore conflicts with a static definition of
the prototype, but can be persuaded to warn if the extern is explicit.
(gcc does this, making it unsuitable as the only compiler to use for
testing).
... and a 3rd reason is that 'extern' is not optional for
variables.
Wrong.
Most traditional Unix linkers will allow the same variable
to be declared without 'extern' in multiple object files and merge
them into only one, but this behaviour is not a feature one should
rely on. And it fact, at least the Darwin linker treats this as an
error.
If so, then the Darwin linker is defective. ISO Standard C variables do NOT
require the extern modifier in order to have external linkage. A variable
at file scope without an initializer is automatically extern.
file_1.c
#include stdio.h
int xxx;
int main()
{
printf( xxx is %d\n, xxx );
return 0;
}
file_2.c
int xxx = 8;
Those two files comprise an ANSI/ISO compliant C program which produces a
well-defined result. A compiler which fails to compile this is not ISO
compliant.
--
- Tim Roberts, [EMAIL PROTECTED]
Providenza Boekelheide, Inc.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: ansifying xwininfo.c
Thomas Dickey wrote: If a function's not used outside a given file, there's no reason to mark it extern... This is the minimum work to get this program into ansi shape. This patch is ready for inclusion. If their are no objections to the patch, it would be very nice to get this in ASAP. It will make some other projects I am working on go smoother. Thanks, Warren Turkal -- President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Warning related to SOCKLEN_TYPE in Xserver/os/xdmcp.c
On Tue, Sep 09, 2003 at 08:21:43AM +0200, Matthieu Herrb wrote: David Dawes wrote (in a message from Monday 8) When building on FreeBSD 4.4 I'm getting the following warnings: The sa_len and sin_len fields are defined on this platform as u_char, while SOCKLEN_TYPE is defined as unsigned int. This looks like a potential problem given that the (u_char *) is dereferenced and written to as an (unsigned int *). oops, yes. What types to other BSD44SOCKETS platforms use for the sa_len and sin_len fields? They are both unsigned chars on Darwin, NetBSD and OpenBSD too. Thanks for checking. I've changed it to unsigned char when BSD44SOCKETS is defined. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
BitBlt for big Endian
Title: Message
HI!
I have written the
following BIt BLT function for the Little endian byte sex.
But same is not
working for theBig endian after doing some changes.Iam using CT 69030
card.
Can any one please
tell how to convert it so that the same function works for both little and big
endian.
The
commented statements were for Little endian.
regards,
Nitin Mahajan
mail:[EMAIL PROTECTED]
Ph:51101667. Mobile :
9886099925
==
The Lord gave us two ends -- one to
sit on and the other to think with. Success depends on which one we use the
most.
/***/
LOCAL VOID
moveDWORDS(register UINT32* puiDest, register UINT32* puiSrc,
register UINT32 uiDwords )
{
/* while(uiDwords ~0x03) {*/
while(uiDwords - (uiDwords % 0x4)){
*puiDest = *(puiSrc+0);
*(puiDest + 1) = *(puiSrc + 1);
*(puiDest + 2) = *(puiSrc + 2);
*(puiDest + 3) = *(puiSrc + 3);
puiSrc += 4;
puiDest += 4;
uiDwords -= 4;
}
switch(uiDwords){
case 1:
*puiDest = *(puiSrc+0);
break;
case 2:
*puiDest = *puiSrc;
*(puiDest + 1) = *(puiSrc + 1);
break;
case 3:
*puiDest = *puiSrc;
*(puiDest + 1) = *(puiSrc + 1);
*(puiDest + 2) = *(puiSrc + 2);
break;
}
}
/***/
LOCAL __inline__ VOID
moveDataFromCPU(UINT8 *pucSrc, UINT8 *pucDest, UINT32 uiSrcwidth,
UINT32 uiWindow, UINT32 uiHeight, UINT32 uiDwords)
{
/*if(uiSrcwidth == (uiDwords 2)) {*/
if(uiSrcwidth == (uiDwords * 4)) {
UINT32 uidecrement = uiWindow / uiDwords;
while(uiHeight uidecrement) {
moveDWORDS((UINT32*)pucDest, (UINT32*)pucSrc, uiDwords * uidecrement);
pucSrc += (uiSrcwidth * uidecrement);
uiHeight -= uidecrement;
}
if(uiHeight) {
moveDWORDS((UINT32*)pucDest, (UINT32*)pucSrc, uiDwords * uiHeight);
}
} else {
while(uiHeight--) {
moveDWORDS((UINT32*)pucDest, (UINT32*)pucSrc, uiDwords);
pucSrc += uiSrcwidth;
}
}
}
/***/
VOID
fb_writeImage(struct SFb_Info *psFb_info,struct SFb_Image *psImage)
{
UINT32 uiBytesPerLine;
UINT32 uiByteWidthSrc;
UINT32 uiDestpitch;
UINT32 uiDwords;
UINT32 uiSkipleft;
UINT32 uiDestAddr;
UINT8 *pucSrc;
UINT32 uiVert;
INT32 iIcount,iJcount;
UINT32 uiXcor,uiYcor,uiWidth,uiHeight,uiSrcwidth,uiBpp;
struct SFb_Info_CT * psFb_CTinfo = (struct SFb_Info_CT *)psFb_info;
struct SCT_par *pspar = psFb_CTinfo-sCurrent_par;
uiXcor = psImage-uiDx;
uiYcor = psImage-uiDy;
uiWidth = psImage-uiWidth;
uiHeight = psImage-uiHeight;
uiBpp = pspar-uicBits_per_pixel;
uiSrcwidth = psImage-uiWidth * pspar-uicBytes_per_pixel;
uiVert = uiHeight;
pucSrc = (UINT8 *)psImage-puicData;
/*uiBytesPerLine = uiWidth * (uiBpp 3);*/
uiBytesPerLine = uiWidth * (uiBpp / 8);
/*uiByteWidthSrc = ((uiSrcwidth * (uiBpp 3) + 3L) ~0x3L);*/
uiByteWidthSrc = ((uiSrcwidth * (uiBpp / 8) + 3L) - ((uiSrcwidth * (uiBpp / 8)
+ 3L) % 0x4));
uiSkipleft = (UINT64)pucSrc % 0x8;
printf(uiSkipleft = %#x\n,uiSkipleft);
printf(pucSrc = %#x\n,(UINT64)pucSrc);
printf((UINT64)pucSrc % 0x8 = %#x\n,(UINT64)pucSrc % 0x8);
printf((UINT64)pucSrc 0x7 = %#x\n,(UINT64)pucSrc 0x7);
/*uiSkipleft = (UINT64)pucSrc 0x7;*/
/*pucSrc = (UINT8 *)((UINT64)pucSrc ~0x7L);*/
pucSrc = (UINT8 *)((UINT64)pucSrc - ((UINT64)pucSrc % 0x8));
uiDwords = ((uiSkipleft + uiBytesPerLine + 0x7) - ((uiSkipleft + uiBytesPerLine
+ 0x7) % 0x8)) / 4;
/*uiDwords = (((uiSkipleft + uiBytesPerLine + 0x7) ~0x7)) 2;*/
/*uiDestAddr = (uiYcor * pspar-uisXRes + uiXcor) * (uiBpp 3);*/
printf(uiYcor = %d\n,uiYcor);
uiDestAddr = (uiYcor * pspar-uisXRes + uiXcor) * (uiBpp / 8);
/*
* To write RGB data beyond the max address which can be stored
* in the destination address register.
*/
if(uiDestAddr = 0x1f)
{
printf(Came atleast once in the if\n);
for(iJcount=0;iJcountuiHeight;iJcount++)
for(iIcount=0;iIcountuiWidth;iIcount++)
{
((volatile UINT8
*)(psFb_CTinfo-uilFrame_Buffer+uiDestAddr))
[iJcount*pspar-uisXRes*(uiBpp /
8)+iIcount*3+1] =
pucSrc[((iJcount)*uiWidth+(iIcount))*3+1];
Intel 845GE with ADD card (Chrontel CH7009A) - DVI out
I'm trying to get my HTPC working. HARDWARE: Aopen MX4GE motherboard: - Intel 845GE chipset for onboard video. Aopen ADD card: - Chrontel CH7009A chipset for S-video and DVI out. Toshiba 30HF83 HDTV. SOFTWARE: XFree86 Version 4.3.0 (Red Hat Linux release: 4.3.0-2) - using the i810 driver. I can get DVI out working at 640x480. It looks great but I can't seem to get any other resolutions though. I've seen some discussions relating the problems with configuring the Intel chipsets through anything but the video BIOS allowed parameters. Is this going to be an insurmountable problem for me? ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Intel 845GE with ADD card (Chrontel CH7009A) - DVI out
On Tue, Sep 09, 2003 at 05:10:39PM -0700, Jeff Christensen wrote: I'm trying to get my HTPC working. HARDWARE: Aopen MX4GE motherboard: - Intel 845GE chipset for onboard video. Aopen ADD card: - Chrontel CH7009A chipset for S-video and DVI out. Toshiba 30HF83 HDTV. SOFTWARE: XFree86 Version 4.3.0 (Red Hat Linux release: 4.3.0-2) - using the i810 driver. I can get DVI out working at 640x480. It looks great but I can't seem to get any other resolutions though. I've seen some discussions relating the problems with configuring the Intel chipsets through anything but the video BIOS allowed parameters. Is this going to be an insurmountable problem for me? Without seeing the XFree86 log file, I have to guess, but it's possible that you just need to increase the amount of video memory pre-allocated at boot time to 8MB. This is set in one of the BIOS config screens. If that doesn't help, send the log file. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [directfb-dev] Re: blanking of non-refreshing windows
Quoting Michel Dänzer ([EMAIL PROTECTED]): On Thu, 2003-08-21 at 23:12, Andy Isaacson wrote: On Fri, Aug 15, 2003 at 12:06:18PM +0200, Michel Dänzer wrote: On Wed, 2003-08-13 at 16:29, Andy Isaacson wrote: I'm not familiar with how those two X servers operate, so could you help me out by explaining? How do they handle window obscures? How is it different from X11's BackingStore? I don't know a lot of details yet, but they indeed always keep the contents of windows around and composite the desktop with them (actually, they have another windowing system do this, but that's not the point). Seems to me you've got to break X11 semantics in order to do this: I suppose they must disable PartiallyObscured events, otherwise the hidden portion of the app windows won't get updated. Right, in XDirectFB overlapping top level windows don't obscure or expose each other. Each top level window has its own surface in (video) memory. After a bunch of updates done by the application, the screen region affected by these changes is recomposed by blitting the window surfaces to the layer's surface (screen). Alpha blended windows are blitted via TMU, at least with a Matrox. In other words, we already had windows being a texture three years ago, Longhorn has it now. (Personally, I'd consider even outdated window contents more useful than unrelated contents or none at all until the client handles the expose event?) There's no old content. Applications still draw to regions that are not visible to the user (yet). too often the BS pixmap is too old, and the X server writes it to the framebuffer only to have it overwritten by the app as soon as it's scheduled. Well, do you want the windows to be refreshed ASAP or not? :) I don't think this is a big deal as the windows will be kept in video RAM whenever possible. I want the window contents to be correct, or at least, innocuous. I agree that if the backing store is kept in the off-screen framebuffer the overhead is minimal; I don't think XFree86's BS implementation can do that. Right. I haven't noticed much difference in general with my every day apps, except that XDirectFB looks and feels snappier and smoother. That's because a) there are much less expose events an b) each single drawing operation is not immediately visible to the user. Therefor a clear plus some drawing appears at once. But it depends on the interactivity of the server and the client. It flickers rarely. In general I want the system to work correctly an in a performant manner even if the number of windows exceeds available off-screen framebuffer memory. It would be interesting how it performs in that case indeed; I don't expect it to be too bad though as it was quite usable even without any hardware acceleration. The surface manager of DirectFB kicks out older window surfaces if no free space is available. Only if many windows overlap while being transparent, it could slow down noticably, because all windows are needed to recompose the stack. But with a 32MB card I have space for many windows ;) -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | -- Convergence GmbH ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
