Re: CapsLock behaviour and Turkish keyboard
Kaixo! On Thu, Aug 07, 2003 at 09:51:36PM +0700, Ivan Pascal wrote: Well, I used to like that behaviour of typewriter capslock (with shift key removing the caps lock, and the capslock affecting all keys and being a shift lock in fact) Unfortunately I can't imagine how to make such mode (affects all keys but Shift cancels Caps ) in XKB. Well, I described how it worked on mechanical typewriters; just having a ShiftLock is enough. (OTOH it is a long time since I last used a mechanical typewriter, and since I discovered the CapsLock on computers (allowing to have uppercase of ccedilla for example), I like this better. On typewritters the Shift Lock was useful to type lots of numbers (on French and Belgian keyboars, digits are on second shift position); but on computers there is the numeric keyopad...) - when idotless is paired with I, then I is used as the uppercase; otherwise CapsLock has no effect on that letter and the lowercase idotless is returned. Probably ConvertCase procedure doesn't know how to convert it to uppercase. Where is the list of internal case pairs ? the lowercase (the letters may be different, eg: [ x, A ] will work. Right. As I said xkbcomp just wants the first symbol be lowercase and the second one be uppercase to consider the key as alphabetic. Yes, and a very wise design, it allows a solution for special uppercasing (there is the Turkish i, but also the eng and schwa/turned e (there exists two variants for the uppercase for both letters); and maybe others) So it seems the problem is indeed solved; but the behaviour (a quite good one in fact) is different of what you and I thought it was. Yes. Thank you for your experiments. I wrote a test program that prints keysyms for all keys in a map for all combinations of Lock and Shift. And than I ran it for all layouts in both modes and compared the results. There are few differences (in 'tr' for example) and in all cases caps:shift produces more reasonable result. Could I get that program somewhere? I didn't noticed any difference at all in my experiments; and I would like to know what those differences are... There is one only exeption in 'ca' and 'ca_enhanced' maps: the key [ eth,Dstroke ]. It's recognized as alphabetical one IMHO that is clearly a bug, it should be [ eth, ETH ] (or [ eth, dstroke ]). Probably introduced by someone not aware of the character difference between ETH and Dstroke, and basing the keyboard map only in visual appareance). So, if that is the only reason not to make caps:shift the default, then it may be dismissed. (and the Canadian keyboard map should be fixed to have either [ eth, ETH ] or [ eth, dstroke ] ) (lowercase - uppercase letters) and the results are different. Lock with caps:internal gives ETH but with caps:shift it gives Dstroke (and there is not way to get ETH). Mmmh; I don't see any difference in behaviour at all between caps:shift and caps:internal ! But I see a difference between old (in /xkb/ ) and new (in .../xkb/pc/ ) keymaps. Old ones behave as in your description of caps:internal; new ones behaves as in your description of caps:shift I tested with [ a, Greek_OMEGA ], when the keyboard is listed as old one; then CapsLock gives A; when it is listed as new layout, then CapsLock gives Greek_OMEGA. (So, the solution for the Turkish keyboard problems would be to use only new layout ones; it solves my problem, but I wonder how I don't see any difference when using -option caps:shift or -option caps:internal) Also there is a problem with new 'one group' keymaps that appeared in 4.3.0. In such keymap there are many four-level keys. The problem is that third and fourth levels in some cases is an alphabetic pair but in some other is not, therefore they should be processed differently for different kinds of four-level keys. But I made only one 'alphabetic' rule for all such keys and too simplified procedure for recognizing them as alphabetic (it checks only two first levels and ignores others). Yes; each pair of unshifted/shifted symboles should be treated separately (there may be [ less, greater, ae, AE ], as well as [ q, Q, at, micron ], and [ o, O, oe, OE ] ) Now I see that I have to improve such keys processing. But when it be done I think we can make caps:shift mode the default. Yes. (I still wonder why I don't see any difference between caps:shift and caps:internal; nor why old and new layouts act differently...) -- Ki ça vos våye bén, Pablo Saratxaga http://chanae.walon.org/pablo/ PGP Key available, key ID: 0xD9B85466 [you can write me in Walloon, Spanish, French, English, Italian or Portuguese] pgp0.pgp Description: PGP signature
Static server build problems in via driver
There's a bunch of undefined references from the via driver that are breaking a static XFree86 server with the current CVS. Some look like variables that have been partially converted to stuct members, and at least one looks like a function that's incorrectly disabled for static builds. A static build is much better for finding problems like this than the default build (where they'll show up as run-time problems instead). ../../programs/Xserver/hw/xfree86/drivers/libdriver.a(via_drv.o): In function `VIAScreenInit': via_drv.o(.text+0x37ec): undefined reference to `FillGraphicInfo' ../../programs/Xserver/hw/xfree86/drivers/libdriver.a(via_drv.o): In function `VIAModeInit': via_drv.o(.text+0x3b72): undefined reference to `FillGraphicInfo' via_drv.o(.text+0x3b90): undefined reference to `Save_3C4_16' via_drv.o(.text+0x3bae): undefined reference to `Save_3C4_17' via_drv.o(.text+0x3bcc): undefined reference to `Save_3C4_18' ../../programs/Xserver/hw/xfree86/drivers/libdriver.a(via_drv.o): In function `viaWaitHQVDone': via_drv.o(.text+0x1dabd): undefined reference to `MPEG_ON' ../../programs/Xserver/hw/xfree86/drivers/libdriver.a(via_drv.o): In function `viaDDOver_GetSrcStartAddress': via_drv.o(.text+0x1e218): undefined reference to `MPGDevice' via_drv.o(.text+0x1e21e): undefined reference to `MPGDevice' via_drv.o(.text+0x1e231): undefined reference to `MPGDevice' via_drv.o(.text+0x1e23c): undefined reference to `MPGDevice' via_drv.o(.text+0x1e248): undefined reference to `MPGDevice' ../../programs/Xserver/hw/xfree86/drivers/libdriver.a(via_drv.o)(.text+0x1e250): more undefined references to `MPGDevice' follow Also, there's a dozen or so global data symbols in the via driver that don't have 'via'-prefixed names. A quick grep shows some of them should simply be static. Others should be renamed (or possibly be struct members). David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: cvsup problems
Sounds like your using an old cvsup binary with glibc-2.3. This is exactly
what I got.
You need to recompile cvsup for glibc-2.3.
I suspect as you work for RedHat, you've probably upgraded to RH9.
Alan.
On Fri, Aug 08, 2003 at 12:09:30PM -0400, John Dennis wrote:
I had been using cvsup successfully to sync with the XFree86 CVS tree,
but after returning from vacation it has started to fail with what
appears to be an internal error in the client.
***
*** runtime error:
***Segmentation violation - possible attempt to dereference NIL0
***
use option @M3stackdump to get a stack trace
Aborted
I will include the stackdump below and my config file, I didn't see
anything in the stackdump that meant anything to me. I did update my
cvsup client to the latest and I checked the cvsup web site looking for
possible causes/solutions. The only thing I found was if you DNS could
not reverse map your ip address you could get a similar failure, but my
DNS server can do the reverse mapping fine. So I'm a bit perplexed,
anybody have a suggestion as to what may be the problem. Like I said,
this has all been working fine previously. The only thing I can think of
is that my host machine did have some libraries updated but cvsup is
statically linked so I don't think that could explain the sudden
failure.
$ cvsup @M3stackdump cvsup.xfree86
***
*** runtime error:
***Segmentation violation - possible attempt to dereference NIL0
***
- STACK DUMP ---
PC SP
0x80c9c18 0xbfffe130 Crash + 0x58 in
/usr/local/src/m3/pm3-1.1.15/libs/m3core/src/runtime/common/RTProcess.m3
0x80c8d6f 0xbfffe144 EndError + 0x3f in
/usr/local/src/m3/pm3-1.1.15/libs/m3core/src/runtime/common/RTMisc.m3
0x80c8b74 0xbfffe168 FatalErrorI + 0x34 in
/usr/local/src/m3/pm3-1.1.15/libs/m3core/src/runtime/common/RTMisc.m3
0x80cd46a 0xbfffe17c SegV + 0x2a in
/usr/local/src/m3/pm3-1.1.15/libs/m3core/src/runtime/LINUXLIBC6/RTSignal.m3
0x80eafb8 0xbfffe4f0
0x8106e0c 0xbfffe538
0x810694b 0xbfffe5fc
0x8106f36 0xbfffe628
0x8101ef9 0xbfffe634
0x810694b 0xbfffe6f8
0x8101772 0xbfffe758
0x8101dff 0xbfffe774
0x811b2d7 0xbfffe78c
0x8102c9d 0xbfffe7e4
0x810285c 0xbfffe83c
0x80a7e8e 0xbfffea0c CanGet + 0x16e in
/usr/local/src/m3/pm3-1.1.15/libs/libm3/src/uid/POSIX/MachineIDPosix.m3
0x80a7238 0xbfffea28 Init + 0x58 in
/usr/local/src/m3/pm3-1.1.15/libs/libm3/src/uid/Common/TimeStamp.m3
0x80a73b1 0xbfffea94 New + 0x81 in
/usr/local/src/m3/pm3-1.1.15/libs/libm3/src/uid/Common/TimeStamp.m3
0x80a69a1 0xbfffead0 RandomSeed + 0x41 in
/usr/local/src/m3/pm3-1.1.15/libs/libm3/src/random/Common/Random.m3
0x80a6876 0xbfffeae4 Init + 0x46 in
/usr/local/src/m3/pm3-1.1.15/libs/libm3/src/random/Common/Random.m3
0x8066467 0xbfffeb1c New + 0x87 in
/usr/local/src/cvsup/cvsup-snap-16.1d/client/src/BackoffTimer.m3
0x806895b 0xb0bc
0x80c869f 0xb0d4 RunMainBodies + 0x6f in
/usr/local/src/m3/pm3-1.1.15/libs/m3core/src/runtime/common/RTLinker.m3
-- EXCEPTION HANDLER STACK -
0xbfffe85c RAISES {}
0xbfffea20 RAISES {}
0xbfffea60 LOCK mutex = 0x81842ec
0xbfffea6c RAISES {}
0xbfffeac8 RAISES {}
0xbfffec34 TRY-FINALLY proc = 0x8068d73 frame = 0xb0bc
0xbfffecfc TRY-EXCEPT {Main.Error}
0xbfffee68 TRY-EXCEPT {Thread.Alerted}
Aborted
Here is my cvsup config file:
*default release=cvs host=anoncvs.xfree86.org
base=/home/boston/jdennis/.cvsup
*default prefix=/home/boston/jdennis/src/xfree86 delete use-rel-suffix
*default compress
*default tag=.
xc-all
doctools-all
contrib-all
xtest-all
utils-all
--
John Dennis [EMAIL PROTECTED]
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: XInput improvements
Alex Deucher wrote: this should be extended to video drivers as well allowing you to dynamically adjust that. I believe THomas Winischofer has done something simialr with his sisctl utility and the sis driver, although I haven't really looked to closely at how that works yet. He has an easier time, given that he has XvGetPortAttribute and XvSetPortAttribute. Just make XAtoms out of his parameters and pass them up and down. Very quick reading of the man page shows you can pass a single XAtom at a time. Would rather have a one-to-many convention to keep communications overhead down... -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xfree86 for the VIA Apollo CLE266
On Sat, Aug 09, 2003 at 08:43:55PM +0200, Sven Luther wrote: On Sat, Aug 09, 2003 at 02:36:01PM -0400, David Dawes wrote: Alternatively, we could use the almost same effect by somehow having the XFree86.0.log include the latest CHANGELOG entry number. This could be done by some preprocessing. If the date in the first XFree86 line is full, and we have a normal release, or it is marked as xx or some other sign, and we are facing a CVS checkout. In this case, we use the first number in the line just below the XFree86 line, and embed that number in the log message writing code. I think I can extract the date from the '$XFree86' line in the CHANGELOG file and add it to the auto-generated xf86Build.h. While I'm at it, I can adjust the auto-generation of xf86Build.h so that its modification time doesn't change when its contents don't change. I've attached a patch for this. Nice. But that would mean not using a xxx as day of the month as is currently done (or was last i checked out the tree). No, it gets it from the '$XFree86' line at the end. For the current CVS trunk, CLOG_DATE gets defined to 20030808, and the following is printed when you run 'XFree86 -version': XFree86 Version 4.3.99.9 Release Date: 8 August 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: FreeBSD 4.4-RELEASE-p1 i386 [ELF] Build Date: 09 August 2003 Changelog Date: 08 August 2003 David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xfree86 for the VIA Apollo CLE266
On Fri, Aug 08, 2003 at 02:21:28AM -0400, David Dawes wrote: On Fri, Aug 08, 2003 at 06:41:58AM +0200, Sven Luther wrote: On Thu, Aug 07, 2003 at 04:52:02PM -0400, David Dawes wrote: On Wed, Jul 30, 2003 at 06:50:28PM -0400, George Georgalis wrote: On Tue, Jul 29, 2003 at 11:59:06PM -0400, David Dawes wrote: On Tue, Jul 29, 2003 at 09:37:06PM -0400, George Georgalis wrote: I heard (second hand from via) that xfree86 2.3.99 has drivers for the CLE266 ( http://www.via.com.tw/en/apollo/cle266.jsp on a http://www.viavpsd.com/product/epia_m_spec.jsp?motherboardId=81 ) I got the cvs source this morning and it built without errors on my fast box. It's been compiling (for a while now) on the hardware I plan to run it from. I assume all will be okay. Here's my next question. After poking around in the source I found ./programs/Xserver/hw/xfree86/drivers/via/ Lots of good stuff in that directory for making the CLE266 work... only how do in invoke it and confirm it's being run? It's confusing to me how a program (eg mplayer) would know to use xfree (and the cle266) for mpeg-2 decoding and not just do the decoding on its own. 4.3.99.9 has a known build problem (which you're seeing). Either try 4.3.99.8, or get the latest code via anoncvs. Humm, a README in that directory could contain note to that effect? or the changelog could be reissued for that file? Thanks for the fast responce anyhow. These are automatically generated code snapshots and nothing more. If you look at http://www.xfree86.org/develsnaps/ you'll see that there is no guanrantee that any given snapshot will build or run. BTW - how do I tell what version of cvs I got? Assuming you checked out the trunk (which is the default), you got the lastest development code as of the time you checked it out. The version is something later than the previous snapsnot. What about marking the version as 4.3.99.x for the snapshot, and once it is released, mark the version as 4.3.99.x+ or 4.3.99.x+co date for the CVS versions, until a new snapshot is taken. Maybe it could only be done in the XFree86.0.log output code, and not the actual version be changed. I usually update the date in xf86Date.h when committing. That gives some indication, and is printed on the line after the version in the log file. I don't think it matters that much personally, but if I wanted to achieve something like this for my own checkouts, I'd use a script that did something like this: #!/bin/sh date=`date` cvs co xc echo #undef XFree86CustomVersion xc/config/cf/host.def echo #define XFree86CustomVersion \$date\ xc/config/cf/host.def I'm not sure how you'd make cvs automatically create a reliable date for all possible ways of checking out the source. Using a CVS date variable or something such, which the XFree86CustomVersion would be set to when taking it out of CVS, and which you would remove before doing the snapshots ? Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
