Re: Broken X11 After Mandriva Upgrade
Adam Jackson wrote: On Wed, 2008-11-26 at 23:27 -0200, Paulo César Pereira de Andrade wrote: Remove the x11-driver-video-sun... packages listed above. They were being build and installed by default, but they won't work on a normal ix86 computer. Making one wonder why you build them for architectures that do not, and will never, have sbus attached. Don't look at me. I wasn't working for Mandriva when those started being installed by default. I just changed the rpm specs to not install them on newer versions... But it is good that it can build on x86, so, while it cannot be executed, compiler warnings can be checked, and one can check for missing symbols (other then the sbus ones). Paulo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Siliconmotion driver update for XFree 4.3?
Gerhart, Bjoern wrote: Dear list, Hi, in the past, our company got a siliconmotion driver update to release 1.4.9 of the siliconmotion driver. But it seems that the features of the 1.4.9 release have not been given back to the xorg developer community. I have the source code for this release, and it can be compiled against XFree 4.3. It is not that it has not been given back, in most cases, it is just that they lost contacts with opensource developers, or there wasn't any developer working on integrating their patches. I have the latest sources from siliconmotion, and I have been on contact with them for some time now. If you are using XFree86, probably you will want to use that version, that you can also get from http://www.loongson.cn/support/cgi-bin/gitweb/gitweb.cgi?p=siliconmotion/xorg;a=summary You may also want to check the latest freedesktop git, just run: git clone git://anongit.freedesktop.org/xorg/driver/xf86-video-siliconmotion There isn't yet an official version, so you need a snapshot. But some of the features in that driver include randr 1.2 (with multihead), exa, basic composite accel, compatible with xorg latest xorg xserver, etc. Now as we want to change to newer Linux distributions, also the Xorg version increases to Xorg 7.1 or newer. But: On the one hand the siliconmotion driver part of Xorg 7.1 does not have the features we had in release 1.4.9. On the other hand I can not simply recompile the 1.4.9 sources against Xorg 7.1. What features you had? Anyway, note that I am working mainly on the smi 501/502 support, but Francisco Jerez did a lot of work for the Lynx3D chipsets, and is the main author of several new features like the randr 1.2 (I only adapted that code to smi 501). I have been working on an some experiments with a drm module for the smi 501, the hardware doesn't have 3d support, but it has a batch buffer and dma transfers from/to system/video memory, and Francisco also did some work on implementing composite on top of Lynx3D hardware. Hopefully that can also be integrated soon. Does it make sense when I create a diff between my siliconmotion 1.4.9 source code and the original siliconmotion source code part of XFree 4.3? Maybe with such a patch, there would be a simple way to port the new siliconmotion driver release to the current Xorg version? They are already in version 2.2.8, while we are on version 1.6.1 :-) If you can send me the tarball it should be easier to handle, then real diffs. As there may exist useful features that were removed... btw: sorry for the long signature at the bottom, it's automatically added :-( Best Regards Björn Paulo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Tabs/spaces coding style question
Jeremy Huddleston wrote: FTR, the replacement of 8 spaces with a tab in indentation is one of my biggest pet-peeves in poor coding etiquette. Either use a tab consistently to denote one level of indentation and have people setup their editor to display tabs differently, or force spaces and /bop people over the head when they have a tab in leading whitespace. This probably was generated by the fact that there was a CodingStyle document that said that X server and libraries should use 4 spaces indentation. One sensible solution would be to only use spaces, but people also likes the idea of using tabs for compressing files. This mix that some of the code currently employs just makes my editor wonkey because it treats the tabs as 4-spaces because of my 4-space-indentation setting (yes, I could probably change my editor settings, but I don't want to, and I shouldn't have to)... AFAIK all unix (not counting recent qt/gtk text widgets) editors use 8 spaces tabs, while windows and mac ones use 4 (or 2) spaces. I think there was a quote from Linus Torvalds, where he says that a tab is 8 spaces, and changing it is like trying to change the value of pi... On Nov 19, 2008, at 10:46, Adam Jackson wrote: On Wed, 2008-11-19 at 09:57 -0800, Dan Nicholson wrote: Sorry for the bikeshed question, but I'm confused by what style I should be using when patching the server. It seems that the consensus is 4-space indentation, and that's fine. But I keep seeing that when the opening indentation is at least 8, real tabs are used to fill as much as possible. Is that the intention? If not, should I keep that style when patching into code that does? I don't care what style is used. Really, this is the sort of thing we should just enforce in a commit hook. At which point it doesn't matter what your editor does. - ajax Paulo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Moving xkbcomp into the server
Peter Hutterer wrote: On Tue, Nov 18, 2008 at 03:44:32AM -0800, Dan Nicholson wrote: I agree completely. As soon as I looked at the path taken in XkbDDXNamesFromRules, I realized how insane it was that there were all these conversions. I'm just moving one step at a time here, with the first one being: leave the retarded conversion path in place, but move the converter into the server. The next step would be to actually start removing parts of the conversion process, but that will take a little more effort. A bit offtopic, but I think xkb really lacks a tool like xkeycaps http://www.jwz.org/xkeycaps/ Xkb configuration is not something trivial, and a program like that would be very useful. But I think the right path should be not move xkbcomp to the X Server, at least not without a major xkb redesign, instead, have an external tool (xkbcomp) generate pre compiled keymaps based on a brief description. I think it'd be less effort to leave the converter as-is and remove the need for calling it, but that's a guess only too. So the path is XkbInitKeyboardDeviceStruct:xkb/xkbInit.c - XkbDDXNamesFromRules:xkb/ddxLoad.c this is where all the rules parsing happens, skipping that may save time. - XkbDDXLoadKeymapByNames:xkb/ddxLoad.c this is where xkbcomp is called with the Kcstg format. xkbcomp now parses that into an xkm format - XkmReadFile:xkb/xkmread.c here we read in the compiled keymap and basically copy it into the internal structs. Right. So, ideally what would happen is: 1. Skip parsing completely if the rules haven't changed. 2. Go directly from RMLVO-internal structs. Or at least make the intra-conversion states not involve reading/writing/parsing files. right, you'd go from oh, same RMLVO to xkmRead() directly. In theory, you could just memcpy the structs from another device but that's not a task for the faint-hearted. Cheers, Peter Paulo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
Adam Jackson wrote: There is still one major bugfix that was only ever applied to 1.5 branch and not master: commit 7822a3d05f935cca3bfa47d15d961596652ecfca Author: Adam Jackson [EMAIL PROTECTED] Date: Tue Jun 17 16:10:51 2008 -0400 XAA: Disable offscreen pixmaps by default. Say Option XaaOffscreenPixmaps to turn them back on. Apropos of bugs #13795 and #15098. Not yet applied to master as this wants a proper solution someday, but then, those bugs aren't closed yet either. Other than that I think the fixes in 1.5.x are a strict subset of what's in master. I'll probably wind down the 1.5 series with one last release when 1.6.0 goes out. Probably not related to those bugs, but XAA doesn't have a flag to call the sync function for screen to screen copy after every sub blit on hardware that has only 2 directions copy. There was a certain crash with the siliconmotion driver (smi 502) a few seconds after opening youtube, due to the animations on the web page overflowing the engine and locking the entire system. Disabling xaa offscreen pixmaps caused it to do enough computations to not overflow the engine... After changing the xaa code to ensuring the engine is idle before every subsequent screen to screen copy, the problem was corrected. - ajax Paulo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] libXaw 1.0.5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Subject: [ANNOUNCE] libXaw 1.0.5 To: xorg-announce@lists.freedesktop.org CC: [EMAIL PROTECTED] Colin Harrison (1): Add MINGW32 definition Dan Nicholson (2): Be more robust using ed for the libtool hacks Use sed instead of ed for libtool SONAME hacking Daniel Stone (2): Remove Xaw8 (Xprint) Remove last remaining vestiges of Xprint support Lee Leahu (1): Fix configure error when using libtool-2.2.* Matthieu Herrb (1): Makefile.am: nuke RCS Id Paulo Cesar Pereira de Andrade (4): Remove almost 10 year old notice about Xaw development from man page. Minor set of trivial corrections. Correct build on systems that did not yet upgrade to libtool-2.2 libXaw version 1.0.5. git tag: libXaw-1.0.5 http://xorg.freedesktop.org/archive/individual/lib/libXaw-1.0.5.tar.bz2 MD5: 64e7782db4653cb57c7f7e660b2431c3 libXaw-1.0.5.tar.bz2 SHA1: fb436a6ed72aa577b4b73397465f1e06844b954f libXaw-1.0.5.tar.bz2 http://xorg.freedesktop.org/archive/individual/lib/libXaw-1.0.5.tar.gz MD5: 0a21177f8bb6d3e4e32e7417a7b7aaf1 libXaw-1.0.5.tar.gz SHA1: c8826e69770686b26bb83f1af80d1f5c03ed966b libXaw-1.0.5.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkkUh5sACgkQPdKBRUa20MDgIgCgnNyAqxMoaLg40W4wF6V54f+j mkIAn3BMm3794gi3B8Md2JnIXV+XSS71 =KQqG -END PGP SIGNATURE- ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] xedit 1.1.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Huddleston (1): Fixed filename conflict during compilation on case-insensitive file systems. Paulo Cesar Pereira de Andrade (3): Proper implementation of AddDoubleClickCallback Rewrite double click confirmation code. Xedit version 1.1.2. Peter Breitenlohner (1): enabled VPATH build git tag: xedit-1.1.2 http://xorg.freedesktop.org/archive/individual/app/xedit-1.1.2.tar.bz2 MD5: 67193be728414d45a1922911e6437991 xedit-1.1.2.tar.bz2 SHA1: e2d9f49dd7e82959e0678c2417256cd59b06772f xedit-1.1.2.tar.bz2 http://xorg.freedesktop.org/archive/individual/app/xedit-1.1.2.tar.gz MD5: 72edacf87bcdb720cafd89b12656c357 xedit-1.1.2.tar.gz SHA1: 8eb53868fcf5220a075fc2a550dc936bd3e05e5e xedit-1.1.2.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkkUjtcACgkQPdKBRUa20MCvWwCZAcoo4qm+syzazuMyMgEMPMOG 4BEAn0jD63rWlVsKF/golKVd4Tpq+z87 =L/Km -END PGP SIGNATURE- ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] libXaw 1.0.5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Subject: [ANNOUNCE] libXaw 1.0.5 To: [EMAIL PROTECTED] CC: xorg@lists.freedesktop.org Colin Harrison (1): Add MINGW32 definition Dan Nicholson (2): Be more robust using ed for the libtool hacks Use sed instead of ed for libtool SONAME hacking Daniel Stone (2): Remove Xaw8 (Xprint) Remove last remaining vestiges of Xprint support Lee Leahu (1): Fix configure error when using libtool-2.2.* Matthieu Herrb (1): Makefile.am: nuke RCS Id Paulo Cesar Pereira de Andrade (4): Remove almost 10 year old notice about Xaw development from man page. Minor set of trivial corrections. Correct build on systems that did not yet upgrade to libtool-2.2 libXaw version 1.0.5. git tag: libXaw-1.0.5 http://xorg.freedesktop.org/archive/individual/lib/libXaw-1.0.5.tar.bz2 MD5: 64e7782db4653cb57c7f7e660b2431c3 libXaw-1.0.5.tar.bz2 SHA1: fb436a6ed72aa577b4b73397465f1e06844b954f libXaw-1.0.5.tar.bz2 http://xorg.freedesktop.org/archive/individual/lib/libXaw-1.0.5.tar.gz MD5: 0a21177f8bb6d3e4e32e7417a7b7aaf1 libXaw-1.0.5.tar.gz SHA1: c8826e69770686b26bb83f1af80d1f5c03ed966b libXaw-1.0.5.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkkUh5sACgkQPdKBRUa20MDgIgCgnNyAqxMoaLg40W4wF6V54f+j mkIAn3BMm3794gi3B8Md2JnIXV+XSS71 =KQqG -END PGP SIGNATURE- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xedit 1.1.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Huddleston (1): Fixed filename conflict during compilation on case-insensitive file systems. Paulo Cesar Pereira de Andrade (3): Proper implementation of AddDoubleClickCallback Rewrite double click confirmation code. Xedit version 1.1.2. Peter Breitenlohner (1): enabled VPATH build git tag: xedit-1.1.2 http://xorg.freedesktop.org/archive/individual/app/xedit-1.1.2.tar.bz2 MD5: 67193be728414d45a1922911e6437991 xedit-1.1.2.tar.bz2 SHA1: e2d9f49dd7e82959e0678c2417256cd59b06772f xedit-1.1.2.tar.bz2 http://xorg.freedesktop.org/archive/individual/app/xedit-1.1.2.tar.gz MD5: 72edacf87bcdb720cafd89b12656c357 xedit-1.1.2.tar.gz SHA1: 8eb53868fcf5220a075fc2a550dc936bd3e05e5e xedit-1.1.2.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkkUjtcACgkQPdKBRUa20MCvWwCZAcoo4qm+syzazuMyMgEMPMOG 4BEAn0jD63rWlVsKF/golKVd4Tpq+z87 =L/Km -END PGP SIGNATURE- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RandR1.2 related patches for the siliconmotion driver
Francisco Jerez wrote: Hi, Hi, I'm attaching some patches with slight improvements to the RandR1.2 implementation in the siliconmotion driver (already committed, but probably it would be a good thing if someone with different hardware than mine was interested on testing the dualhead modesetting code). I was making some experiments using a different approach to try to have redimensionable virtual screen with XAA, but probably not worth the work required, so I think it is better to use your patch, and require a fixed size :-) (I was just thinking of not needing to add options to xorg.conf and still using XAA as default...) The patches mainly fix video overlay and hardware cursor. I've written an incomplete Composite implementation to accelerate screen rotations, so I think it doesn't make sense anymore to keep shadowfb support, and I have removed it, and I have done some more clean up. I adapted the cursor code to the smi 501/502, and will make some more tests with video. Then, I will apply some minor changes as a patch after yours. Should do it still today... Paulo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Ansification of X.Org code other cleanup work
Peter Breitenlohner wrote: On Mon, 20 Oct 2008, Alan Coopersmith wrote: If someone wanted to organize a janitorial squad to tackle these and help new people work through them to get to the point where they were ready for commit access, we'd love you forever (or at least until you turn us down when we then volunteer you to be the next release manager). [2] 41 open bugs: http://bugs.freedesktop.org/buglist.cgi?keywords=janitorproduct=Xorgbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENED Hi Paulo, looking through that list, I noticed that your #15082 (app/xfs) has already addressed a problem (redefined) I also noticed recently. You also mention two other problems: I fully agree with the prototype and declaration BecomeDaemon (void). To Paulo and Alan, I'm not so sure about Paulos proposal to add a prototype for SnfSetFormat in xfs/os/config.c. I'd rather think that this function ought to be declared in one of the headers installed by libXfont. (Is there a policy decision?) I think I just followed some pattern elsewhere, but really, prototypes should be in header files, and the file actually defining the function should also include that header. To all, moreover, I think one should add if test x$GCC = xyes; then GCC_WARNINGS=-Wall -Wpointer-arith -Wstrict-prototypes \ -Wmissing-prototypes -Wmissing-declarations \ -Wnested-externs -fno-strict-aliasing CFLAGS=$GCC_WARNINGS $CFLAGS fi to each and every configure.ac (if not already present) and address the problems uncovered this way. For ansification, you would also want at least -Wold-style-definition. I also used -Wbad-function-cast and -Wdeclaration-after-statement, but I think I only submited patches for code mixed with declarations, what I think is now supported by Xorg (I just dislike it :-), if one needs new variables, start a new block, otherwise pray all compilers will have the same semantics, i.e. variables have function scope or block scope, etc). To Paulo and Alan, there are additional problems with xfs: The xfs(1) manpage states (under -daemon) that the daemon will delete the pidfile upon exit: not true. In addition SetDaemonState in xfs/os/utils.c has code to produce an error message that another xfs process is already running. This never happens because StorePid always return either 0 or -1, and would be problematic because there may well be two daemons using different ports. Fact is, however, that when I try to start a second daemon on the same port, that process overwrites the original pidfile and then dies (probably because it can't create the socket). Not very nice. I don't remember all the details, but if you look at http://cvsweb.xfree86.org/cvsweb/xc/programs/xfs/ seven years ago I did several patches for xfs, to correct an exploit, but instead of just fixing the exploit, I made a program that would connect and feed /dev/urandom data as packets. I think I corrected like 50 buffer overruns just by doing that, until it stayed like one week properly handling the random data (and closing connection, etc). But most likely it did not check all combinations, and one could start adding random data after some initial valid data exchange have been done; this could also be done for the X Server, or any kind of server (and probably there should already exist some kind of generic stress test tool for this kind of test somewhere). regards Peter Breitenlohner [EMAIL PROTECTED] Paulo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Ansification of X.Org code other cleanup work
Alan Coopersmith wrote: From a comment in a patch Peter recently submitted: libXpm is one of the libraries that still could need ANSIfication, I'd offer some help if you tell me to do so. It is not ansified, but it doesn't have problematic functions, i.e. KR prototypes with char/short/float arguments/return-type like libX11. But libX11 has it only on non public or hard to get access to, locale related functions. And this has come up on #xorg-devel recently and in patches submitted by Paulo in the past...(and probably a couple times a year since we started X.Org)... In general, I think everyone agrees conversion of the remaining bits of code that use KR/pre-ANSI-C89 style function prototypes declarations to C89 is a good thing (provided it's done correctly [1]), but that none of the people doing most of the work on Xorg have much time to help with it. The same applies to much other janitorial type work, like cleaning up gcc warnings and all the bugs with the janitor keyword ([2]), and all the patches sitting in bugzilla ([3]) or the mailing list archives. We get patches submitted by people like Paulo Peter, and while some of us try to get through the backlog in our spare time, the backlog of them grows faster than we can get time to get through them. xorg/app/old-xt-xaw-applications is a good place to practice ansification :-) I'd really like to encourage the people who want to tackle these issues to get someone to help them apply their first few patches, then apply for git commit access so you can commit them directly, because if you wait for the few of us trawling the submitted patches to get to them, many of your patches will be uselessly out-of-sync with the code by the time we get to them and you'll be seeing those errors for months or longer until we do. I closed most ansification bugreports opened by me, as I was not sure it was intended to actually work on it; I only applied patches that actually corrected real problems. The patches should still be available, on the closed bug reports (at some point I think I had like 50 of these patches open). One place that I did not submit patches was the X Server, as I wanted it to be done after having my visibility patches applied first, as those, while not adding a real visible functionality add the oportunity to have a more clean sdk, with only what is expected to be visible by outside modules, actually visible, and all the other benefits :-) If someone wanted to organize a janitorial squad to tackle these and help new people work through them to get to the point where they were ready for commit access, we'd love you forever (or at least until you turn us down when we then volunteer you to be the next release manager). [1] http://invisible-island.net/ansification/index.html [2] 41 open bugs: http://bugs.freedesktop.org/buglist.cgi?keywords=janitorproduct=Xorgbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENED [3] 122 open bugs, though many patches aren't keyworded: http://bugs.freedesktop.org/buglist.cgi?keywords=patchproduct=Xorgbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENED Paulo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [sis 671/771 drivers]
Benjamin Wech wrote: Hi, I looked up your faq about a possibly release of a working SIS 771/671 3D driver, but haven't found an affirmative answer. So I have to ask when it would be possible to use opengl/3D with this chip considering the fact it seems to be available for Windows, and following the post on this blog http://barroslee.blogspot.com/2007/09/release-sis671sis672-linux-3d-driver.html it should also be available for Linux - but nevertheless nobody gets You should try contacting SiS. I have some binaries (but no card), but they probably would not help much now. Needs kernel 2.6.22, xorg 1.3, and mesa 6.x (and need to replace libGL.so.1.2, and libdrm.so.2.0.0). this driver. So would it be possible to run 3D with this chip and a X.org driver in future-releases? And how long would this take according to your expectations? Sincere regards Benjamin Wech P.S. Hope this text will be understandable, because I'm not really sure about my english. It is ok, but a subject would help :-) Paulo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: SMI 501 local bus driver
Christian Pössinger wrote: Hi, I figured out the UseFBDev function yesterday. When enabling this specific function my screen shows up with the mighty X cursor. I can move it with Does it also happen when using the SwCursor option? my mouse perfectly, but the background is only black. I can't see the normal b/w X background. When I start the xterm it's black, too. It appears as if the driver is writing to one address, and the kernel to other. If you run something like: # dd if=/dev/urandom of=/dev/fb0 bs=1024 count=1024 does it show something on the screen? Please open a bugreport on bugs.freedesktop.org, and also test the latest git master. Paulo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: SMI 501 local bus driver
Christian Pössinger wrote: Now I used the latest siliconmotion driver from the XOrg GIT and removed the PCI function calls to access the device via Local Plus Bus of the TQM5200 board. I initialize the pSmi-MapBase and pSmi-FbBase fields with a mmap() call to /dev/mem and the proper adresses. After the module started up I see the following output with X -verbose 9 Does the kernel framebuffer work? In that case, there is a fallback option UseFBDev, that will not attempt to program the hardware, other then the accel registers. == (II) Loading sub module ramdac (II) LoadModule: ramdac(II) Module ramdac already built-in (II) do I need RAC? No, I don't. (II) resource ranges after preInit: [0] 0 0 0xe3e0 - 0xe400 (0x21) MX[B] [1] -1 0 0x0010 - 0x3fff (0x3ff0) MX[B]E(B) [2] -1 0 0x000f - 0x000f (0x1) MX[B] [3] -1 0 0x000c - 0x000e (0x3) MX[B] [4] -1 0 0x - 0x0009 (0xa) MX[B] [5] -1 0 0x8000 - 0x8003 (0x4) MX[B] [6] -1 0 0x - 0x (0x1) IX[B] [7] -1 0 0x - 0x00ff (0x100) IX[B] (II) SMI(0): Physical MMIO at 0xE3E0 (II) SMI(0): Logical MMIO at 0x48a4c000 - 0x48c4bfff (II) SMI(0): DPR=0x48b4c000, VPR=0x48a4c000, IOBase=(nil) (II) SMI(0): DataPort=0x48b5c000 - 0x48b6bfff (II) SMI(0): Physical frame buffer at 0xE000 offset: 0x (II) SMI(0): Logical frame buffer at 0x48c4c000 - 0x4944bfff (II) SMI(0): Cursor Offset: 007FF800 (II) SMI(0): Reserved: 007FF000 (II) SMI(0): FrameBuffer Box: 0,480 - 640,6550 (II) SMI(0):SMI_GEReset called from smi_accel.c line 131 (II) SMI(0):SMI_GEReset called from smi_accel.c line 64 (II) SMI(0):SMI_GEReset called from smi_accel.c line 64 == This is completely illogical in the current sources, but it matches SMI sources I received, it just checks if PCIRetry is enabled in the WaitQueue() macro, see regsmi.h:195. I hope to investigate it soon, to understand why a macro that should be checking the fifo, just ignores it's argument, and does something completely different... The driver doesn't display anything now, instead it calls the SMI_GEReset function until I reset the device. When I set pSmi-NoAccel = TRUE; there seems to be no call to SMI_GEReset, at least none is displayed on the console, but the display is still black. I would appreciate it if anyone is able to supply me with a flash of inspiration. Other then the UseFBDev option. I hope to have a more complete mode setting code soon, based on more recent information I received from SMI; information about the 502 clocks, and the differences with earlier releases, that are not clearly documented in the pdfs available at ftp.siliconmotion.com. Best regards, Christian Paulo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xedit 1.1.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Corrects missing util.h in xedit-1.1.0 tarball. For packagers, non implicit dependencies are: x11-bitmaps (xorg/data/bitmaps), aspell, aspell-en, grep, words, ctags, x11-font-alias (xorg/fonts/alias), x11-font-dec-misc (xorg/fonts/dec-misc), x11-font-misc (xorg/fonts/misc), x11-font-adobe-75-dpi (xorg/fonts/adobe-75dpi), x11-font-adobe-100-dpi (xorg/fonts/adobe-100dpi), x11-font-bh-lucidatypewriter-75dpi (xorg/fonts/bh-lucidatypewriter-75dpi), x11-font-bh-lucidatypewriter-100dpi (xorg/fonts/bh-lucidatypewriter-100dpi), x11-font-bh-75dpi (xorg/fonts/bh-75dpi), x11-font-bh-100dpi (xorg/fonts/bh-100dpi) Paulo Cesar Pereira de Andrade (1): Correct make dist and update to xedit-1.1.1. git tag: xedit-1.1.1 http://xorg.freedesktop.org/archive/individual/app/xedit-1.1.1.tar.bz2 MD5: 37ff67afb10c2846d3709f5e8a7b661d xedit-1.1.1.tar.bz2 SHA1: 2097aef4c297f673d42750e327be918fbb448a53 xedit-1.1.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/app/xedit-1.1.1.tar.gz MD5: c9f953eb24a3aa78f690f13b189b6796 xedit-1.1.1.tar.gz SHA1: e175f7b984de40f894ce5472d43d3435cacfccc0 xedit-1.1.1.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkiR+BkACgkQPdKBRUa20MDzTwCeJBdSjsL/OMIxRyOKbstR1O5i pmMAoJsGpKrgSeKXZZ1m3ue6Zv0JJhOp =fWSm -END PGP SIGNATURE- ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] xedit 1.1.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Subject: [ANNOUNCE] xedit 1.1.0 To: xorg-announce@lists.freedesktop.org James Cloos (3): Rename .cvsignore to .gitignore Add *~ to .gitignore to skip patch/emacs droppings Replace static ChangeLog with dist-hook to generate from git log Paulo Cesar Pereira de Andrade (23): Fix a bug in the regex library Add updated/meaningful README, COPYING and AUTHORS files. Update build for sane defaults. Add a generic hash table interface to replace the other implementations. Readd support for *international resource and default to false. Make ispell interface work correctly again. Fix several generic bugs including: Fix several problems in the line edit mode. Generic lisp interface bug fixes including: Add support to enter line number in command line. Update syntax highlight table and some minor tweaks including: Add a tags interface to xedit. Add support for scrolling textwindow with mouse wheel. Add perl and auto tools modes. Fix an incorrect buffer size calculation and allocation. Support multiple make jobs. Compile warning fixes. Add python mode. Warn if a newer version of a file exists before overwritting it. Fix an off by one error check that can lead to an infinite loop. CancelFindFile is almost the same as XeditFocus, and could be merged in a Update file type pattern matching. Update to xedit 1.1.0. git tag: xedit-1.1.0 http://xorg.freedesktop.org/archive/individual/app/xedit-1.1.0.tar.bz2 MD5: acfa1b798501f0a22c090cad7e5639eb xedit-1.1.0.tar.bz2 SHA1: 442fc4fdb7fbb909448ba2ccba96af2fd140f717 xedit-1.1.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/app/xedit-1.1.0.tar.gz MD5: c95f222ce65f2272ab5b472fb7f5b368 xedit-1.1.0.tar.gz SHA1: f1af09b40f376cfa06737fbf826152aeb7e4 xedit-1.1.0.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkiQ8zYACgkQPdKBRUa20MCZeQCfUc/cwfnK70YXg4C3BeO9BJhE eacAoIOKk7zPNMa5T4s5V9raLoFAgPhL =yv+l -END PGP SIGNATURE- ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
