Pander invites you to check out Dropbox
Hi there, Pander invites you to try Dropbox! Dropbox lets you bring all your photos, docs and videos with you anywhere and share them easily. Accept invite. https://www.dropbox.com/l/1JCF1g9COD0pUpCaf1YXdj Thanks! - The Dropbox Team To stop receiving invites from Dropbox, please go to https://www.dropbox.com/l/LdgAZaLsumxUT4ITmWDFDi Dropbox, Inc., PO Box 77767, San Francisco, CA 94107___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: (Crowd funded) fix for SiS 671/771 video cards
On 05/20/2013 04:58 AM, Connor Behan wrote: > On 19/05/13 09:48 AM, Pander wrote: >> On 05/18/2013 10:28 PM, Tormod Volden wrote: >>> On Sat, May 18, 2013 at 7:52 PM, Pander wrote: >>>> (manual) patch results in >>>> >>>> [74.465] (II) LoadModule: "sisimedia" >>>> [74.465] (II) Loading /usr/lib/xorg/modules/drivers/sisimedia_drv.so >>>> [74.465] (EE) Failed to load >>>> /usr/lib/xorg/modules/drivers/sisimedia_drv.so: >>>> /usr/lib/xorg/modules/drivers/sisimedia_drv.so: undefined symbol: >>>> SiSUploadToScratch >>>> [74.465] (II) UnloadModule: "sisimedia" >>>> [74.465] (II) Unloading sisimedia >>>> [74.465] (EE) Failed to load module "sisimedia" (loader failed, 7) >>>> >>>> I used this file: http://pastebin.com/XkYfxrQy >>> It would be more useful if you told which file it is and which version >>> instead of paste-binning it. I assume this is the src/sis310_accel.c >>> from git://gitorious.org/xf86-video-sis671/sis-671-fix.git >> Sorry, I forgot indeed that filename. I have removed declarations and >> usage of SiSUploadToScreen, SiSUploadToScratch and SiSDownloadFromScreen. >> >> Do I need to do that also for >> void SiSScratchSave(ScreenPtr pScreen, ExaOffscreenArea *area); >> ? >> > No, that can be left in. Sorry for messing up the patch. It works. Here is the Xorg log file. Switching to console with CTRL+ALT+F1 etc still doesn't work however. See the top pf the file for loading of the driver and the bottom (probably) for switching to console and back: http://pastebin.com/VA7dVBjL Using Option "UseTiming1366" "true" in the Device section still causes screen to remain black. the log file for that is: http://pastebin.com/7t2XWRpQ Attached are the patches for my current version. I have tried to contact the author via https://gitorious.org/xf86-video-sis671/sis-671-fix but I have not yet received any response. In his log file I see some syncing with Xorg so (in response of Alan's message of the 12th of May, the author might be interested to contribute this to Xorg. I have send him a message again if he can help out with a this. What can be done next to get : - console working - acceleration support - driver shipped with Xorg - other improvements (fix compiler warnings, UseTiming1366, etc.) Regards, Pander > > > > ___ > xorg-devel@lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: http://lists.x.org/mailman/listinfo/xorg-devel > --- sis_accel.c.orig 2013-05-20 11:23:36.280836820 +0200 +++ sis_accel.c 2013-05-19 18:46:07.753545455 +0200 @@ -55,9 +55,6 @@ #ifdef SIS_USE_EXA extern void SiSScratchSave(ScreenPtr pScreen, ExaOffscreenArea *area); -extern Bool SiSUploadToScreen(PixmapPtr pDst, int x, int y, int w, int h, char *src, int src_pitch); -extern Bool SiSUploadToScratch(PixmapPtr pSrc, PixmapPtr pDst); -extern Bool SiSDownloadFromScreen(PixmapPtr pSrc, int x, int y, int w, int h, char *dst, int dst_pitch); #endif /* EXA */ extern UChar SiSGetCopyROP(int rop); @@ -862,8 +859,8 @@ SiSAccelInit(ScreenPtr pScreen) /* Composite not supported */ /* Upload, download to/from Screen */ - pSiS->EXADriverPtr->UploadToScreen = SiSUploadToScreen; - pSiS->EXADriverPtr->DownloadFromScreen = SiSDownloadFromScreen; +// pSiS->EXADriverPtr->UploadToScreen = SiSUploadToScreen; +// pSiS->EXADriverPtr->DownloadFromScreen = SiSDownloadFromScreen; #endif /*end of Xorg>=7.0 EXA Setting*/ } @@ -949,7 +946,7 @@ SiSAccelInit(ScreenPtr pScreen) //#if XORG_VERSION_CURRENT <= XORG_VERSION_NUMERIC(7,0,0,0,0) // pSiS->EXADriverPtr->accel.UploadToScratch = SiSUploadToScratch; //#else - pSiS->EXADriverPtr->UploadToScratch = SiSUploadToScratch; +//svg pSiS->EXADriverPtr->UploadToScratch = SiSUploadToScratch; //#endif } --- sis_3daccel.c.orig 2013-05-20 11:23:43.716836455 +0200 +++ sis_3daccel.c 2013-05-19 18:43:46.729552378 +0200 @@ -91,9 +91,6 @@ #ifdef SIS_USE_EXA /* EXA */ void SiSScratchSave(ScreenPtr pScreen, ExaOffscreenArea *area); -Bool SiSUploadToScreen(PixmapPtr pDst, int x, int y, int w, int h, char *src, int src_pitch); -Bool SiSUploadToScratch(PixmapPtr pSrc, PixmapPtr pDst); -Bool SiSDownloadFromScreen(PixmapPtr pSrc, int x, int y, int w, int h, char *dst, int dst_pitch); #endif /* EXA */ --- sis310_accel.c.orig 2013-05-20 11:23:15.780837827 +0200 +++ sis310_accel.c 2013-05-18 18:38:22.582402302 +0200 @@ -101,9 +101,6 @@ static CARD32 SiSDstTextureFormats32[3] #ifdef SIS_USE_EXA /* EXA */ void SiSSc
Re: (Crowd funded) fix for SiS 671/771 video cards
On 05/18/2013 10:28 PM, Tormod Volden wrote: > On Sat, May 18, 2013 at 7:52 PM, Pander wrote: >> (manual) patch results in >> >> [74.465] (II) LoadModule: "sisimedia" >> [74.465] (II) Loading /usr/lib/xorg/modules/drivers/sisimedia_drv.so >> [74.465] (EE) Failed to load >> /usr/lib/xorg/modules/drivers/sisimedia_drv.so: >> /usr/lib/xorg/modules/drivers/sisimedia_drv.so: undefined symbol: >> SiSUploadToScratch >> [74.465] (II) UnloadModule: "sisimedia" >> [74.465] (II) Unloading sisimedia >> [74.465] (EE) Failed to load module "sisimedia" (loader failed, 7) >> >> I used this file: http://pastebin.com/XkYfxrQy > > It would be more useful if you told which file it is and which version > instead of paste-binning it. I assume this is the src/sis310_accel.c > from git://gitorious.org/xf86-video-sis671/sis-671-fix.git Sorry, I forgot indeed that filename. I have removed declarations and usage of SiSUploadToScreen, SiSUploadToScratch and SiSDownloadFromScreen. Do I need to do that also for void SiSScratchSave(ScreenPtr pScreen, ExaOffscreenArea *area); ? > >> >> How can I fix this? >> > > Connor's pastebin patch only removed SiSUploadToScratch() from that > one file. You will have to remove all references to that function. > "git grep SiSUploadToScratch" will help you. > > Regards, > Tormod > ___ > xorg-devel@lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: http://lists.x.org/mailman/listinfo/xorg-devel > ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: (Crowd funded) fix for SiS 671/771 video cards
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/12/2013 12:16 PM, Connor Behan wrote: > On 10/05/13 01:23 AM, Pander wrote: >> On 05/07/2013 09:24 PM, Connor Behan wrote: >>> On 07/05/13 06:17 AM, Pander wrote: >>>>> On 7 May 2013 14:04, Pander >>>>> wrote: >>>>> >>>>> The sis671 driver: >>>>>> # xorg.conf (X.Org X Window System server configuration >>>>>> file) >>>>> ... >>>>>> Section "Device" Identifier "Configured Video >>>>>> Device" Driver "sis671" Option >>>>>> "NoAccel" "true" EndSection >>>>> ... >>>>> >>>>> doesn't seem to be a proper module: >>>>>> http://pastebin.com/fwXeTCq1 >>>>> ... [ 12247.125] (II) LoadModule: "sis671" [ 12247.125] >>>>> (II) Loading /usr/lib/xorg/modules/drivers/sis671_drv.so [ >>>>> 12247.125] (EE) LoadModule: Module sis671 does not have a >>>>> sis671ModuleData data object. [ 12247.125] (II) >>>>> UnloadModule: "sis671" [ 12247.125] (II) Unloading sis671 [ >>>>> 12247.125] (EE) Failed to load module "sis671" (invalid >>>>> module, 0) ... >>>> It used to be a properly working module. See >>>> https://bugs.launchpad.net/linuxmint/+bug/301958/comments/202 >>>> on support for XAA acceleration needed for this driver. >>> SiS drivers support EXA and will probably use that by default >>> when you start one of the newer Xservers that lacks XAA. This >>> could easily crash if the SiS EXA hooks haven't been updated in >>> awhile so that's why I suggested "NoAccel" to help diagnose the >>> problem. >>>>> Then it tries the other sis driver: ... [ 12247.125] (II) >>>>> LoadModule: "sis" [ 12247.125] (II) Loading >>>>> /usr/lib/xorg/modules/drivers/sis_drv.so ... This one >>>>> looks like it doesn't support your card. (No 671 listed in >>>>> within the supported chipsets.) >>>>> >>>>>> from and >>>>>> http://ajoliveira.com/ajoliveira/gen/bin/sis_driver_64-bit_12.04.tar.gz >>>>>> >>>>>> >> >>>>>> on >>>>>> Ubuntu 13.04 >>>>> (Haven't had time to look into this.) >>> I can only find binary blob drivers on that site. A search for >>> xf86-video-sis671 source turned up >>> https://gitorious.org/xf86-video-sis671 so try compiling that. >>> A comment by an Arch user mentioned something about it working >>> in 2013 but the module was renamed to sisimedia. >>> >> Thanks. Here is the latest version that works with NoAccel: >> https://gitorious.org/xf86-video-sis671/sis-671-fix >> >> Section "Device" Identifier "Configured Video Device" Driver >> "sisimedia" Option "NoAccel" "true" EndSection >> >> Section "Monitor" Identifier "Configured Monitor" EndSection >> >> Section "Screen" Identifier "Default Screen" Monitor >> "Configured >> Monitor" Device "Configured Video Device" DefaultDepth 24 >> EndSection >> >> The log file is here: http://pastebin.com/nSpWUB7S >> >> When acceleration is enabled it freezes the system completely. >> Usually with the left side of the screen purple (Ubuntu) and the >> right side of the screen in many different colors (memdump?). >> That logfile is here: http://pastebin.com/HKBcCySP >> >> At least I can use my laptop again at maximum resolution. >> However, the acceleration support that was working should be >> fixed. Who is can help out? > It looks like the SiS driver never did compositing which is what > the majority of EXA problems are about. It must be the UTS / DFS > hooks. Here is a patch to remove them http://pastebin.com/74NqqmN2 > which is fine because they do the same thing that a software > fallback would do. (manual) patch results in [74.465] (II) LoadModule: "sisimedia" [74.465] (II) Loading /usr/lib/xorg/modules/drivers/sisimedia_drv.so [74.465] (EE) Failed to load /usr/lib/xorg/modules/drivers/sisimedia_drv.so: /usr/lib/xorg/modules/drivers/sisimedia_drv.so: undefined symbol: SiSUploadToScratch [74.465] (II) UnloadModule: &
Re: (Crowd funded) fix for SiS 671/771 video cards
On 05/10/2013 08:13 PM, Tormod Volden wrote: > On Fri, May 10, 2013 at 11:04 AM, Pander wrote: >>> On 05/07/2013 09:24 PM, Connor Behan wrote: > >>>> SiS drivers support EXA and will probably use that by default when >>>> you start one of the newer Xservers that lacks XAA. This could >>>> easily crash if the SiS EXA hooks haven't been updated in awhile so >>>> that's why I suggested "NoAccel" to help diagnose the problem. > > Connor, first, thanks a lot for caring for these old drivers. A lot of > people are still using their old laptops and run the latest Linux > distributions on them. > > Thanks especially for the hint you gave earlier in this thread: "EXA > callbacks that use the devPrivate.ptr of a pixmap." I am trying to > keep the savage driver working, but I don't have the capacity to > follow xorg development in detail. Recently an EXA problem came up for > which I had no clue. Reading your hint was enough to guide me in the > right direction and now I believe I have fixed it with a one-liner > change. > >> Xorg works but when I press CTRL+ALT+F1 I get a screen with an unusable >> screen. I see a small part of Xorg repeated a lon on the left side and >> on the right side many different colors. This part works with the older >> SiS driver for other cards. > > Pander, does console switching work with the vesa driver? It doesn't > on my savage card, so I wonder if it is a more general non-KMS > problem. You say it works with the older SiS driver though, was that > also on the latest xserver? > Yes it worked and was on Ubuntu 13.04 xorg 2:1.13.3-0ubuntu6 Also, when booting and no X has been loaded the screen also works. > Regards, > Tormod > ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: (Crowd funded) fix for SiS 671/771 video cards
On 05/10/2013 10:23 AM, Pander wrote: > On 05/07/2013 09:24 PM, Connor Behan wrote: >> On 07/05/13 06:17 AM, Pander wrote: >>>> On 7 May 2013 14:04, Pander >>>> wrote: >>>> >>>> The sis671 driver: >>>>> # xorg.conf (X.Org X Window System server configuration >>>>> file) >>>> ... >>>>> Section "Device" Identifier "Configured Video Device" >>>>> Driver "sis671" Option "NoAccel" >>>>> "true" EndSection >>>> ... >>>> >>>> doesn't seem to be a proper module: >>>>> http://pastebin.com/fwXeTCq1 >>>> ... [ 12247.125] (II) LoadModule: "sis671" [ 12247.125] (II) >>>> Loading /usr/lib/xorg/modules/drivers/sis671_drv.so [ >>>> 12247.125] (EE) LoadModule: Module sis671 does not have a >>>> sis671ModuleData data object. [ 12247.125] (II) UnloadModule: >>>> "sis671" [ 12247.125] (II) Unloading sis671 [ 12247.125] (EE) >>>> Failed to load module "sis671" (invalid module, 0) ... >>> It used to be a properly working module. See >>> https://bugs.launchpad.net/linuxmint/+bug/301958/comments/202 on >>> support for XAA acceleration needed for this driver. >> >> SiS drivers support EXA and will probably use that by default when >> you start one of the newer Xservers that lacks XAA. This could >> easily crash if the SiS EXA hooks haven't been updated in awhile so >> that's why I suggested "NoAccel" to help diagnose the problem. >>> >>>> Then it tries the other sis driver: ... [ 12247.125] (II) >>>> LoadModule: "sis" [ 12247.125] (II) Loading >>>> /usr/lib/xorg/modules/drivers/sis_drv.so ... This one looks >>>> like it doesn't support your card. (No 671 listed in within the >>>> supported chipsets.) >>>> >>>>> from and >>>>> http://ajoliveira.com/ajoliveira/gen/bin/sis_driver_64-bit_12.04.tar.gz >>>>> >>>>> > on >>>>> Ubuntu 13.04 >>>> (Haven't had time to look into this.) >> >> I can only find binary blob drivers on that site. A search for >> xf86-video-sis671 source turned up >> https://gitorious.org/xf86-video-sis671 so try compiling that. A >> comment by an Arch user mentioned something about it working in >> 2013 but the module was renamed to sisimedia. >> > > Thanks. Here is the latest version that works with NoAccel: > https://gitorious.org/xf86-video-sis671/sis-671-fix > > Section "Device" > Identifier "Configured Video Device" > Driver "sisimedia" > Option "NoAccel" "true" > EndSection > > Section "Monitor" > Identifier "Configured Monitor" > EndSection > > Section "Screen" > Identifier "Default Screen" > Monitor "Configured Monitor" > Device "Configured Video Device" > DefaultDepth24 > EndSection > > The log file is here: > http://pastebin.com/nSpWUB7S > > When acceleration is enabled it freezes the system completely. Usually > with the left side of the screen purple (Ubuntu) and the right side of > the screen in many different colors (memdump?). That logfile is here: > http://pastebin.com/HKBcCySP > > At least I can use my laptop again at maximum resolution. However, the > acceleration support that was working should be fixed. Who is can help > out? Xorg works but when I press CTRL+ALT+F1 I get a screen with an unusable screen. I see a small part of Xorg repeated a lon on the left side and on the right side many different colors. This part works with the older SiS driver for other cards. > At the same time, can this driver get included with Xorg so it will > work out of the box with the next release? > ___ > xorg-devel@lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: http://lists.x.org/mailman/listinfo/xorg-devel > ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: (Crowd funded) fix for SiS 671/771 video cards
On 05/07/2013 09:24 PM, Connor Behan wrote: > On 07/05/13 06:17 AM, Pander wrote: >>> On 7 May 2013 14:04, Pander >>> wrote: >>> >>> The sis671 driver: >>>> # xorg.conf (X.Org X Window System server configuration >>>> file) >>> ... >>>> Section "Device" Identifier "Configured Video Device" >>>> Driver "sis671" Option "NoAccel" >>>> "true" EndSection >>> ... >>> >>> doesn't seem to be a proper module: >>>> http://pastebin.com/fwXeTCq1 >>> ... [ 12247.125] (II) LoadModule: "sis671" [ 12247.125] (II) >>> Loading /usr/lib/xorg/modules/drivers/sis671_drv.so [ >>> 12247.125] (EE) LoadModule: Module sis671 does not have a >>> sis671ModuleData data object. [ 12247.125] (II) UnloadModule: >>> "sis671" [ 12247.125] (II) Unloading sis671 [ 12247.125] (EE) >>> Failed to load module "sis671" (invalid module, 0) ... >> It used to be a properly working module. See >> https://bugs.launchpad.net/linuxmint/+bug/301958/comments/202 on >> support for XAA acceleration needed for this driver. > > SiS drivers support EXA and will probably use that by default when > you start one of the newer Xservers that lacks XAA. This could > easily crash if the SiS EXA hooks haven't been updated in awhile so > that's why I suggested "NoAccel" to help diagnose the problem. >> >>> Then it tries the other sis driver: ... [ 12247.125] (II) >>> LoadModule: "sis" [ 12247.125] (II) Loading >>> /usr/lib/xorg/modules/drivers/sis_drv.so ... This one looks >>> like it doesn't support your card. (No 671 listed in within the >>> supported chipsets.) >>> >>>> from and >>>> http://ajoliveira.com/ajoliveira/gen/bin/sis_driver_64-bit_12.04.tar.gz >>>> >>>> on >>>> Ubuntu 13.04 >>> (Haven't had time to look into this.) > > I can only find binary blob drivers on that site. A search for > xf86-video-sis671 source turned up > https://gitorious.org/xf86-video-sis671 so try compiling that. A > comment by an Arch user mentioned something about it working in > 2013 but the module was renamed to sisimedia. > Thanks. Here is the latest version that works with NoAccel: https://gitorious.org/xf86-video-sis671/sis-671-fix Section "Device" Identifier "Configured Video Device" Driver "sisimedia" Option "NoAccel" "true" EndSection Section "Monitor" Identifier "Configured Monitor" EndSection Section "Screen" Identifier "Default Screen" Monitor "Configured Monitor" Device "Configured Video Device" DefaultDepth24 EndSection The log file is here: http://pastebin.com/nSpWUB7S When acceleration is enabled it freezes the system completely. Usually with the left side of the screen purple (Ubuntu) and the right side of the screen in many different colors (memdump?). That logfile is here: http://pastebin.com/HKBcCySP At least I can use my laptop again at maximum resolution. However, the acceleration support that was working should be fixed. Who is can help out? At the same time, can this driver get included with Xorg so it will work out of the box with the next release? ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: (Crowd funded) fix for SiS 671/771 video cards
> On 7 May 2013 14:04, Pander wrote: > > The sis671 driver: >> # xorg.conf (X.Org X Window System server configuration file) > ... >> Section "Device" >> Identifier "Configured Video Device" >> Driver "sis671" >> Option "NoAccel" "true" >> EndSection > ... > > doesn't seem to be a proper module: >> http://pastebin.com/fwXeTCq1 > ... > [ 12247.125] (II) LoadModule: "sis671" > [ 12247.125] (II) Loading /usr/lib/xorg/modules/drivers/sis671_drv.so > [ 12247.125] (EE) LoadModule: Module sis671 does not have a > sis671ModuleData data object. > [ 12247.125] (II) UnloadModule: "sis671" > [ 12247.125] (II) Unloading sis671 > [ 12247.125] (EE) Failed to load module "sis671" (invalid module, 0) > ... It used to be a properly working module. See https://bugs.launchpad.net/linuxmint/+bug/301958/comments/202 on support for XAA acceleration needed for this driver. > > Then it tries the other sis driver: > ... > [ 12247.125] (II) LoadModule: "sis" > [ 12247.125] (II) Loading /usr/lib/xorg/modules/drivers/sis_drv.so > ... > This one looks like it doesn't support your card. (No 671 listed in > within the supported chipsets.) > >> from and >> http://ajoliveira.com/ajoliveira/gen/bin/sis_driver_64-bit_12.04.tar.gz >> on >> Ubuntu 13.04 > (Haven't had time to look into this.) > > Cheers, Daniel > ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: (Crowd funded) fix for SiS 671/771 video cards
> On 07/05/13 02:19 AM, Pander wrote: >>> >>> This is the log file, search for [Ss][Ii][Ss] >> http://pastebin.com/GMhwZXde >> > It looks like the Xserver tries sis, modesetting, fbdev and vesa and > ends up deciding on vesa. In order to see useful information, make sure > X doesn't use a generic driver. Something like Driver "sis" in the > Device section of xorg.conf. Option "NoAccel" "true" should also make a > difference. # xorg.conf (X.Org X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the xorg.conf manual page. # (Type "man xorg.conf" at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # Note that some configuration settings that could be done previously # in this file, now are automatically configured by the server and settings # here are ignored. # # If you have edited this file but would like it to be automatically updated # again, run the following command: # sudo dpkg-reconfigure -phigh xserver-xorg Section "Device" Identifier "Configured Video Device" Driver "sis671" Option "NoAccel" "true" EndSection Section "Monitor" Identifier "Configured Monitor" EndSection Section "Screen" Identifier "Default Screen" Monitor "Configured Monitor" Device "Configured Video Device" DefaultDepth24 EndSection and http://pastebin.com/fwXeTCq1 from and http://ajoliveira.com/ajoliveira/gen/bin/sis_driver_64-bit_12.04.tar.gz on Ubuntu 13.04 > > ___ > xorg-devel@lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: http://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: (Crowd funded) fix for SiS 671/771 video cards
>> On 06/05/13 11:22 PM, Pander wrote: >>> >>> Alan Coopersmith wrote: >>> >>>> On 05/ 6/13 06:22 PM, Connor Behan wrote: >>>>> Maybe you'll find someone who >>>>> has a SiS card lying around and say "I'll pay you $100 to put that >>>> card >>>>> in your computer, write an xorg.conf file for it, figure out why it >>>>> won't start and then change 2 or 3 lines to make it start again" but >>>> it >>>>> won't be worth it. >>>> Especially when you can buy 2 or 3 new ATI or Nvidia cards for that >>>> $100 >>>> and get much better performance & support than trying to make an old >>>> card >>>> limp along forever. >>>> >>>> http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&N=17709%204025&IsNodeId=1&bop=And&Order=PRICE&PageSize=20 >>>> >>> Well, it is an integrated card in my laptop. Because Linux is so >>> resource friendly it is still working fine for its age and I rather >>> donate a small amount than to start selecting and purchasing a new one >>> yet. >>> >> You won't even have to donate a small amount if you post the logs >> already. I really should wait to read them but I will hazard a guess >> about what the bug is anyway: EXA callbacks that use the devPrivate.ptr >> of a pixmap. Try disabling EXA. > > This is the log file, search for [Ss][Ii][Ss] http://pastebin.com/GMhwZXde > > Could you tell me what to test with specific commands? > >>>> The lack of maintainers for many old cards is in large part because >>>> the >>>> cost of a new card with a well-maintained driver is less than people >>>> think >>>> their time is worth for the many hours it takes to bring the old >>>> drivers up >>>> to snuff and test on all the different models. >> >> >> ___ >> xorg-devel@lists.x.org: X.Org development >> Archives: http://lists.x.org/archives/xorg-devel >> Info: http://lists.x.org/mailman/listinfo/xorg-devel > > > ___ > xorg-devel@lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: http://lists.x.org/mailman/listinfo/xorg-devel > ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: (Crowd funded) fix for SiS 671/771 video cards
> On 06/05/13 11:22 PM, Pander wrote: >> >> Alan Coopersmith wrote: >> >>> On 05/ 6/13 06:22 PM, Connor Behan wrote: >>>> Maybe you'll find someone who >>>> has a SiS card lying around and say "I'll pay you $100 to put that >>> card >>>> in your computer, write an xorg.conf file for it, figure out why it >>>> won't start and then change 2 or 3 lines to make it start again" but >>> it >>>> won't be worth it. >>> Especially when you can buy 2 or 3 new ATI or Nvidia cards for that >>> $100 >>> and get much better performance & support than trying to make an old >>> card >>> limp along forever. >>> >>> http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&N=17709%204025&IsNodeId=1&bop=And&Order=PRICE&PageSize=20 >>> >> Well, it is an integrated card in my laptop. Because Linux is so >> resource friendly it is still working fine for its age and I rather >> donate a small amount than to start selecting and purchasing a new one >> yet. >> > You won't even have to donate a small amount if you post the logs > already. I really should wait to read them but I will hazard a guess > about what the bug is anyway: EXA callbacks that use the devPrivate.ptr > of a pixmap. Try disabling EXA. This is the log file, search for [Ss][Ii][Ss] Could you tell me what to test with specific commands? >>> The lack of maintainers for many old cards is in large part because the >>> cost of a new card with a well-maintained driver is less than people >>> think >>> their time is worth for the many hours it takes to bring the old >>> drivers up >>> to snuff and test on all the different models. > > > ___ > xorg-devel@lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: http://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: (Crowd funded) fix for SiS 671/771 video cards
> On 2013-05-07 08:22 (GMT+0200) Pander composed: > >> Alan Coopersmith wrote: > >>> you can buy 2 or 3 new ATI or Nvidia cards for that $100 >>> and get much better performance & support than trying to make an old >>> card >>> limp along forever. > >> Well, it is an integrated card in my laptop. > > The newest SiS video _card_ I can recall ever encountering was made last > century, before Intel began integrating video in motherboard chipsets as a > matter of course. IOW, SiS video is typically a component on a low cost > motherboard, often, maybe usually, on motherboards without slots in which > to > put any video card regardless of price. I bought myself a SiS video > motherboard once. That won't happen again, except maybe under extreme > duress, > neglect or accident. I would also not choose one agaon but it is widely used, see https://www.google.com/search?hl=en&q=sis+771 and https://www.google.com/search?hl=en&q=sis+671 > -- > "The wise are known for their understanding, and pleasant > words are persuasive." Proverbs 16:21 (New Living Translation) > > Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! > > Felix Miata *** http://fm.no-ip.com/ > ___ > xorg-devel@lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: http://lists.x.org/mailman/listinfo/xorg-devel > ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: (Crowd funded) fix for SiS 671/771 video cards
Alan Coopersmith wrote: >On 05/ 6/13 06:22 PM, Connor Behan wrote: >> Maybe you'll find someone who >> has a SiS card lying around and say "I'll pay you $100 to put that >card >> in your computer, write an xorg.conf file for it, figure out why it >> won't start and then change 2 or 3 lines to make it start again" but >it >> won't be worth it. > >Especially when you can buy 2 or 3 new ATI or Nvidia cards for that >$100 >and get much better performance & support than trying to make an old >card >limp along forever. > >http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&N=17709%204025&IsNodeId=1&bop=And&Order=PRICE&PageSize=20 > Well, it is an integrated card in my laptop. Because Linux is so resource friendly it is still working fine for its age and I rather donate a small amount than to start selecting and purchasing a new one yet. >The lack of maintainers for many old cards is in large part because the >cost of a new card with a well-maintained driver is less than people >think >their time is worth for the many hours it takes to bring the old >drivers up >to snuff and test on all the different models. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: (Crowd funded) fix for SiS 671/771 video cards
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/06/2013 10:36 PM, Connor Behan wrote: > On 06/05/13 10:25 AM, pan...@users.sourceforge.net wrote: >> Hi all, >> >> Since a few months the driver for SiS 671/771 video cards is no >> longer working in main stream distributions such as Ubuntu. This >> is affecting many users and I would like to ask the development >> community of Xorg who would like to fix this issue. >> >> For the details please see these bug reports: >> https://bugs.freedesktop.org/show_bug.cgi?id=15190 and: >> https://bugs.launchpad.net/debian/+source/xserver-xorg-video-sis/+bug/301958 >> >> >> Since the number of users waiting for a fix is in the thousands, I am sure >> that some sort of crowd funding such as: >> https://www.catincan.com/proposal/altdrag/altdrag-10 might be >> possible. >> >> I am more than happy to make a financial contribution in order to >> not having to write off some still good hardware. I am sure many >> others are willing to chip in. Who would be interested in taking >> this on? >> >> Regards, >> >> Pander >> > Those bug reports started in 2008 and seem to just track the > stability of the SiS driver in general. Nowhere do I see a > description about the specific problem that has arisen in 2013 with > the proper information (terminal output, dmesg output, lspci > output, xorg.conf file, backtrace, etc). As suggested on the > Launchpad bug report, I would try compiling xf86-video-sisimedia > with the Archlinux patches applied: > https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/xf86-video-sisimedia > > They have put a large amount of effort into keeping this driver working > and have updated the patches in 2013. > My experience with building drivers for Xorg is relatively small. As I recall, this one compiles but crashed Xorg and I don't know exactly what to submit exactly. It is better if the people working on that driver or other Xorg experts give it a try and write a proper analysis of the specific work that needs to be done (probably restoring support that has been removed but that might not be trivial). > If those still don't work, get your hands dirty... if any > particular strings appear in error messages, find those strings in > the source and figure out what function is failing. Then compare > the execution of the broken copy to the last working copy you > remembered. If the API of some dependency changed, use git bisect > to repeatedly compile the kernel or the Xserver until you find the > exact line of code in the dependency that made the difference. > Hacking the driver might sound hard, but it's not so hard that you > have to pay someone to do it. > Well, I don't mind getting my hands dirty but I am already involved in too many other open source project myself at the moment. With so many users of this hardware out there and people getting used to chipping in for applications or features via small donations such as Google Play for Android, I think it is a nice way to show appreciation for their efforts. But if someone would like to start working on it nevertheless-simply because to support users with this kind of hardware-that is also fine. > > > ___ > xorg-devel@lists.x.org: X.Org development Archives: > http://lists.x.org/archives/xorg-devel Info: > http://lists.x.org/mailman/listinfo/xorg-devel > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlGIKeIACgkQ0YurwYIk8CJ3fwCeOAuxcMZS+GUv/YCks2tt5Tia FHAAniQB+WTyLAF1O70O09WqLU5V3fgw =Hbqg -END PGP SIGNATURE- ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
(Crowd funded) fix for SiS 671/771 video cards
Hi all, Since a few months the driver for SiS 671/771 video cards is no longer working in main stream distributions such as Ubuntu. This is affecting many users and I would like to ask the development community of Xorg who would like to fix this issue. For the details please see these bug reports: https://bugs.freedesktop.org/show_bug.cgi?id=15190 and: https://bugs.launchpad.net/debian/+source/xserver-xorg-video-sis/+bug/301958 Since the number of users waiting for a fix is in the thousands, I am sure that some sort of crowd funding such as: https://www.catincan.com/proposal/altdrag/altdrag-10 might be possible. I am more than happy to make a financial contribution in order to not having to write off some still good hardware. I am sure many others are willing to chip in. Who would be interested in taking this on? Regards, Pander ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Patch for compose key sequences J with acute
> On 2013-02-20 17:28, James Cloos wrote: >> One quick review note: >> >> Per 10646 and unicode, that miniscule sequence should >> be "j́" and not "ȷ́". > > Do you mean (only fix in tyop in quote of my proposal): > > "j́" and not "ȷ́". > > I just noticed that on bitmap fonts such as the command line, one still > sees the dot of the j or a j followed by a filled diamond shape. > >> The i and j are defined to have soft dots; all combining sequence >> starting with either MUST ignore the dot on the base character. >> >> Not all font/rendering engines tuples get this right, but they should, >> and searches et al probably expect j́. > > So indeed there is some work on the rendering part. Attached is a new > patch with you improvement. Does anyone would like to have the reverse > order supported and/or dead keys supported for this? > Could someone sign off patch 0.2 and add it to the repo? See also http://lists.x.org/archives/xorg-devel/2013-February/035544.html >> -JimC >> > > Regards, > > Pander > ___ > xorg-devel@lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: http://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Patch for compose key sequences J with acute
On 2013-02-20 17:28, James Cloos wrote: > One quick review note: > > Per 10646 and unicode, that miniscule sequence should > be "j́" and not "ȷ́". Do you mean (only fix in tyop in quote of my proposal): "j́" and not "ȷ́". I just noticed that on bitmap fonts such as the command line, one still sees the dot of the j or a j followed by a filled diamond shape. > The i and j are defined to have soft dots; all combining sequence > starting with either MUST ignore the dot on the base character. > > Not all font/rendering engines tuples get this right, but they should, > and searches et al probably expect j́. So indeed there is some work on the rendering part. Attached is a new patch with you improvement. Does anyone would like to have the reverse order supported and/or dead keys supported for this? > -JimC > Regards, Pander diff --git a/nls/en_US.UTF-8/Compose.pre b/nls/en_US.UTF-8/Compose.pre index de24dad..6c4dc6f 100644 --- a/nls/en_US.UTF-8/Compose.pre +++ b/nls/en_US.UTF-8/Compose.pre @@ -618,6 +618,7 @@ XCOMM Part 3 : "Ã" Idiaeresis # LATIN CAPITAL LETTER I WITH DIAERESIS : "Ã" Idiaeresis # LATIN CAPITAL LETTER I WITH DIAERESIS : "Ã" Idiaeresis # LATIN CAPITAL LETTER I WITH DIAERESIS + : "JÌ"# LATIN CAPITAL LETTER J U004A with COMBINING ACUTE ACCENT U0301 : "Ã" ETH # LATIN CAPITAL LETTER ETH : "Ã" Ntilde # LATIN CAPITAL LETTER N WITH TILDE : "Ã" Ntilde # LATIN CAPITAL LETTER N WITH TILDE @@ -738,6 +739,7 @@ XCOMM Part 3 : "ï" idiaeresis # LATIN SMALL LETTER I WITH DIAERESIS : "ï" idiaeresis # LATIN SMALL LETTER I WITH DIAERESIS : "ï" idiaeresis # LATIN SMALL LETTER I WITH DIAERESIS + : "jÌ"# LATIN SMALL LETTER J U006A with COMBINING ACUTE ACCENT U0301 : "ð" eth # LATIN SMALL LETTER ETH : "ñ" ntilde # LATIN SMALL LETTER N WITH TILDE : "ñ" ntilde # LATIN SMALL LETTER N WITH TILDE ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Patch for compose key sequences J with acute
Hi all, Please review this patch for two additional compose key sequences for J with acute and dotless j with acute. Justification for this is the following usage in the Dutch language: https://nl.wikipedia.org/wiki/Accenttekens_in_de_Nederlandse_spelling#Klemtoonteken Dutch knows the digraph ij and IJ and is used as a vowel sound. To indicate stress, an acute is allowed but must also appear on the j and J. However, j and J are not vowels and are currently not supported with compose key sequences. The following patch fixes this. If someone would like also the reverse order and/or the dead keys supported, please add it to this patch. For the moment, please review this patch. Regards, Pander diff --git a/nls/en_US.UTF-8/Compose.pre b/nls/en_US.UTF-8/Compose.pre index de24dad..0a7d05d 100644 --- a/nls/en_US.UTF-8/Compose.pre +++ b/nls/en_US.UTF-8/Compose.pre @@ -618,6 +618,7 @@ XCOMM Part 3 : "Ã" Idiaeresis # LATIN CAPITAL LETTER I WITH DIAERESIS : "Ã" Idiaeresis # LATIN CAPITAL LETTER I WITH DIAERESIS : "Ã" Idiaeresis # LATIN CAPITAL LETTER I WITH DIAERESIS + : "JÌ"# LATIN CAPITAL LETTER J U004A with COMBINING ACUTE ACCENT U0301 : "Ã" ETH # LATIN CAPITAL LETTER ETH : "Ã" Ntilde # LATIN CAPITAL LETTER N WITH TILDE : "Ã" Ntilde # LATIN CAPITAL LETTER N WITH TILDE @@ -738,6 +739,7 @@ XCOMM Part 3 : "ï" idiaeresis # LATIN SMALL LETTER I WITH DIAERESIS : "ï" idiaeresis # LATIN SMALL LETTER I WITH DIAERESIS : "ï" idiaeresis # LATIN SMALL LETTER I WITH DIAERESIS + : "È·Ì"# LATIN SMALL LETTER DOTLESS J U0237 with COMBINING ACUTE ACCENT U0301 : "ð" eth # LATIN SMALL LETTER ETH : "ñ" ntilde # LATIN SMALL LETTER N WITH TILDE : "ñ" ntilde # LATIN SMALL LETTER N WITH TILDE ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: libX11: Changes to 'master'
On 05/10/2012 06:24 PM, James Cloos wrote:
>>>>>> "JH" == Jeremy Huddleston writes:
>
> JH> This commit introduced a 'make check' failure due by duplicating
> JH> existing entries:
>
> I ran compose-check.pl while reviewing it, but on the .pre files rather
> than on the compiled files. ☹
>
> I'll have to work on a patch to that script to enable its use pre-compile.
>
> Duplicate removal patch on the way
>
> -JimC
The attached check.py can give you some more feedback on the quality of
Compose.pre. Please, try it and see what you can incorporate in the
default check process.
Was someone able to review and apply the patches I have send on May 5th
to resolve outstanding issue before the next release?
Regards,
Pander
#!/usr/bin/env python
# -*- coding: utf-8 -*-
"""
Name check-compose.py
Description Check compose sequences
Author Pander
License MIT License
0.1 2012-01-06 Pander
Initial release
0.2 2012-03-19 Pander
Added downloading
"""
import binascii
import sys
from urllib import urlretrieve
from os.path import isfile, getsize
silent = False
def isUnicodeUpper(s):
hex = ('0', '1', '2', '3', '4', '5', '6', '7', '8', '9', 'A', 'B', 'C', 'D', 'E', 'F', )
if (
len(s) == 5 and s[0] == 'U' and s[1] in hex and s[2] in hex and s[3] in hex and s[4] in hex
) or (
len(s) == 6 and s[0] == 'U' and s[1] in hex and s[2] in hex and s[3] in hex and s[4] in hex and s[5] in hex
):
return True
return False
def isUnicodeLower(s):
hex = ('0', '1', '2', '3', '4', '5', '6', '7', '8', '9', 'a', 'b', 'c', 'd', 'e', 'f', )
if (
len(s) == 5 and s[0] == 'U' and s[1] in hex and s[2] in hex and s[3] in hex and s[4] in hex
) or (
len(s) == 6 and s[0] == 'U' and s[1] in hex and s[2] in hex and s[3] in hex and s[4] in hex and s[5] in hex
):
return True
return False
def download_hook(blocks_transferred, block_size, file_size):
""" A download hook to provide some feedback when downloading """
if blocks_transferred == 0:
if file_size > 0:
if not silent:
print 'INFO: Downloading', file_size, 'bytes:',
else:
if not silent:
print 'INFO: Downloading:',
sys.stdout.write('#')
sys.stdout.flush()
def download_file(url):
""" Downloads a file provided a URL. Returns the filename. """
""" Borks on failure """
localfilename = url.split('/')[-1]
if not isfile(localfilename) or getsize(localfilename) <= 0:
if not silent:
print 'INFO: Downloading', url, '...'
try:
urlretrieve(url, localfilename, download_hook)
except IOError, (errno, strerror):
print 'I/O error(%s): %s' % (errno, strerror)
sys.exit(-1)
except:
print 'Unexpected error:', sys.exc_info()
sys.exit(-1)
print ' done.'
else:
if not silent:
print 'INFO: Using cached file for', url
return localfilename
# Load Unicode information
unicode_info = {}
unicode_file = None
unicode_filename = download_file('http://www.unicode.org/Public/UNIDATA/UnicodeData.txt')
try:
unicode_file = open(unicode_filename, 'r')
except IOError, (errno, strerror):
print 'I/O error(%s): %s' % (errno, strerror)
sys.exit(-1)
except:
print 'Unexpected error:', sys.exc_info()
sys.exit(-1)
for line in unicode_file.readlines():
data = line.split(';')
unicode_info[data[0]] = data[1]
# Load compose sequences
compose_sequences = {}
codes = []
chars = []
names = []
compose_file = None
compose_filename = download_file('http://cgit.freedesktop.org/xorg/lib/libX11/plain/nls/en_US.UTF-8/Compose.pre')
try:
compose_file = open(compose_filename, 'r')
except IOError, (errno, strerror):
print 'I/O error(%s): %s' % (errno, strerror)
sys.exit(-1)
except:
print 'Unexpected error:', sys.exc_info()[0]
sys.exit(-1)
lines = 0
for line in compose_file.readlines():
lines = lines + 1
if line[0] != '<':
continue
if '"\t\t# ' in line:
line = line .replace('"\t\t# ', '"# ')
if ': "' in line and '___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: libX11: Changes to 'master'
On 2012-05-05 05:23, Alan Coopersmith wrote: > On 04/19/12 11:35 AM, Julien Cristau wrote: >> On Tue, Apr 10, 2012 at 17:56:47 +0200, Pander wrote: >> >>> Could you please apply that one already so it is of the list and we >>> discuss the rest below? THanks. >>> >> Please send it properly (such as with git send-email) with a commit >> message, and I'll do that. > > Are we any closer to resolving this? If we're going to be removing > sequences that just got added, I'd rather do that before the release, > instead of waiting for people to get used to using them and breaking > them later.(Adding new stuff can easily wait of course.) > Hi all, As discussed and as promised, see attachments for incremental patches. Please review and if OK, please commit to master. Regards, Pander commit d015b387153308561ff28e664db212242eaeda48 Author: Pander Date: Sat May 5 16:28:01 2012 +0200 Reassigned to oacute, also for upper case. diff --git a/nls/en_US.UTF-8/Compose.pre b/nls/en_US.UTF-8/Compose.pre index 2eae912..c9ff587 100644 --- a/nls/en_US.UTF-8/Compose.pre +++ b/nls/en_US.UTF-8/Compose.pre @@ -647,6 +647,7 @@ XCOMM Part 3 : "Ã" Oacute # LATIN CAPITAL LETTER O WITH ACUTE : "Ã" Oacute # LATIN CAPITAL LETTER O WITH ACUTE : "Ã" Oacute # LATIN CAPITAL LETTER O WITH ACUTE + : "Ã" Oacute # LATIN CAPITAL LETTER O WITH ACUTE : "Ã" Ocircumflex # LATIN CAPITAL LETTER O WITH CIRCUMFLEX : "Ã" Ocircumflex # LATIN CAPITAL LETTER O WITH CIRCUMFLEX : "Ã" Ocircumflex # LATIN CAPITAL LETTER O WITH CIRCUMFLEX @@ -772,6 +773,7 @@ XCOMM Part 3 : "ó" oacute # LATIN SMALL LETTER O WITH ACUTE : "ó" oacute # LATIN SMALL LETTER O WITH ACUTE : "ó" oacute # LATIN SMALL LETTER O WITH ACUTE + : "ó" oacute # LATIN SMALL LETTER O WITH ACUTE : "ô" ocircumflex # LATIN SMALL LETTER O WITH CIRCUMFLEX : "ô" ocircumflex # LATIN SMALL LETTER O WITH CIRCUMFLEX : "ô" ocircumflex # LATIN SMALL LETTER O WITH CIRCUMFLEX @@ -1458,7 +1460,6 @@ XCOMM Part 3 : "Ǻ" U01FA # LATIN CAPITAL LETTER A WITH RING ABOVE AND ACUTE : "Ǻ" U01FA # LATIN CAPITAL LETTER A WITH RING ABOVE AND ACUTE : "Ǻ" U01FA # LATIN CAPITAL LETTER A WITH RING ABOVE AND ACUTE - : "Ǻ" U01FA # LATIN CAPITAL LETTER A WITH RING ABOVE AND ACUTE : "Ǻ" U01FA # LATIN CAPITAL LETTER A WITH RING ABOVE AND ACUTE : "Ç»" U01FB # LATIN SMALL LETTER A WITH RING ABOVE AND ACUTE : "Ç»" U01FB # LATIN SMALL LETTER A WITH RING ABOVE AND ACUTE @@ -1467,7 +1468,6 @@ XCOMM Part 3 : "Ç»" U01FB # LATIN SMALL LETTER A WITH RING ABOVE AND ACUTE : "Ç»" U01FB # LATIN SMALL LETTER A WITH RING ABOVE AND ACUTE : "Ç»" U01FB # LATIN SMALL LETTER A WITH RING ABOVE AND ACUTE - : "Ç»" U01FB # LATIN SMALL LETTER A WITH RING ABOVE AND ACUTE : "Ç»" U01FB # LATIN SMALL LETTER A WITH RING ABOVE AND ACUTE : "Ǽ" U01FC # LATIN CAPITAL LETTER AE WITH ACUTE : "Ǽ" U01FC # LATIN CAPITAL LETTER AE WITH ACUTE commit 7eb2732b8635b7c9766f993075b24475a4a9d226 Author: Pander Date: Sat May 5 16:40:20 2012 +0200 Removed in combination with a numeral for superscript. diff --git a/nls/en_US.UTF-8/Compose.pre b/nls/en_US.UTF-8/Compose.pre index c9ff587..3890053 100644 --- a/nls/en_US.UTF-8/Compose.pre +++ b/nls/en_US.UTF-8/Compose.pre @@ -532,19 +532,11 @@ XCOMM Part 3 : "²" twosuperior # SUPERSCRIPT TWO : "²" twosuperior # SUPERSCRIPT TWO <2> : "²" twosuperior # SUPERSCRIPT TWO - <2> : "²" twosuperior # SUPERSCRIPT TWO - <2> : "²" twosuperior # SUPERSCRIPT TWO - <2> : "²" twosuperior # SUPERSCRIPT TWO - <2> : "²" twosuperior # SUPERSCRIPT TWO <3> : "³" threesuperior # SUPERSCRIPT THREE <3> : "³" threesuperior # SUPERSCRIPT THREE : "³" threesuperior # SUPERSCRIPT THREE : "³" threesuperior # SUPERSCRIPT THREE <3> : "³" threesuperior # SUPERSCRIPT THREE - <3> : "³" threesuperior # SUPERSCRIPT THREE - <3> : "³" threesuperior # SUPERSCRIPT THREE - <3> : "³" threesuperior # SUPERSCRIPT THREE - <3> : "³" threesuperior # SUPERSCRIPT THREE : "µ" mu # M
Re: libX11: Changes to 'master'
Alan Coopersmith wrote: >On 04/19/12 11:35 AM, Julien Cristau wrote: >> On Tue, Apr 10, 2012 at 17:56:47 +0200, Pander wrote: >> >>> Could you please apply that one already so it is of the list and we >>> discuss the rest below? THanks. >>> >> Please send it properly (such as with git send-email) with a commit >> message, and I'll do that. > >Are we any closer to resolving this? If we're going to be removing >sequences that just got added, I'd rather do that before the release, >instead of waiting for people to get used to using them and breaking >them later.(Adding new stuff can easily wait of course.) I will provides patches today. One with what is already agreed upon and some extra patches for the ones under discussion. > >-- > -Alan Coopersmith- alan.coopersm...@oracle.com >Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: libX11: Changes to 'master'
On 2012-04-09 18:21, Julien Cristau wrote: > On Wed, Apr 4, 2012 at 13:28:17 +0200, Pander wrote: > >> On 2012-03-31 13:05, Julien Cristau wrote: >>> On Thu, Mar 22, 2012 at 16:36:27 +0100, Pander wrote: >>> >>>> James, Julien, did you receive enough compelling arguments to resolve >>>> this conflict so that results in ó. Then we can finally >>>> close the book on gtk+/GNOME conflicts. >>>> >>> OK. Can you send a patch? >> >> Sure, see attachtment. Now the apostrophe series is consistent and no >> more gtk+/GNOME conflicts exist, see: >> > That's fine with me. Could you please apply that one already so it is of the list and we discuss the rest below? THanks. I would still argue for reverting some of the > new sequences added in cf040016d455bc37f7665d6714337c5eafd8ea94 though, > e.g. for ¥, §, ¤, ² and so on (I've only looked at the top of the diff). From: http://cgit.freedesktop.org/xorg/lib/libX11/commit/nls/en_US.UTF-8/Compose.pre?id=cf040016d455bc37f7665d6714337c5eafd8ea94 We already threw out several redundant gtk+/GNOME compose sequences for ¤, ¥ and § that were a bit over the top, there mainly 'o' was replaced by a '0' (zero) in additional sequences.. ¤ does indeed not really need XO, OX, oX, Xo, Ox and xO variations in the added compose sequences. These new six sequences are for me not important but are available in gtk+/GNOME. I'm OK with removing: XO OX oX Xo Ox xO For ¥, I would argue to keep the added upper case Y combinations that have been added because the shape of glyph looks like an upper case Y. And also the added lower case sequences to support = and -. For §, a similar reasoning. For ², ³, µ, etc. keep at least the lower case sequences, also the reverse sequences. On the upper case 2S, S2, 3S, S3, U/ and /U I have the same argument as on ¤ above. Doubtful but available in gtk+/GNOME. I'm OK with removing: 2S S2 3S S3 U/ /U > Also you added some sequences like ' <$letter> ' > sometimes for '$letter with tilde', and sometimes for '$letter with > macron', or '$letter with stroke'. For keysyms that already had > existing sequences, and where the new ones don't seem to add much > benefit as far as I can tell. You mean the ã, Ã, ñ, Ñ, õ and Õ created from letter + minus. These are also not important to me. If you all insist I am OK with replacing: a- -a A- -A o- -o O- -O with sequences resulting in āĀōŌ conform the current series and removing: n- -n N- -N Regards, Pander > Cheers, > Julien ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: libX11: Changes to 'master'
On 2012-03-31 13:05, Julien Cristau wrote: > On Thu, Mar 22, 2012 at 16:36:27 +0100, Pander wrote: > >> James, Julien, did you receive enough compelling arguments to resolve >> this conflict so that results in ó. Then we can finally >> close the book on gtk+/GNOME conflicts. >> > OK. Can you send a patch? Sure, see attachtment. Now the apostrophe series is consistent and no more gtk+/GNOME conflicts exist, see: libX11/nls/en_US.UTF-8$ grep 'key> <.> ' Compose.pre : "Á" Aacute # LATIN CAPITAL LETTER A WITH ACUTE : "É" Eacute # LATIN CAPITAL LETTER E WITH ACUTE : "Í" Iacute # LATIN CAPITAL LETTER I WITH ACUTE : "Ó" Oacute # LATIN CAPITAL LETTER O WITH ACUTE : "Ú" Uacute # LATIN CAPITAL LETTER U WITH ACUTE : "Ý" Yacute # LATIN CAPITAL LETTER Y WITH ACUTE : "á" aacute # LATIN SMALL LETTER A WITH ACUTE : "é" eacute # LATIN SMALL LETTER E WITH ACUTE : "í" iacute # LATIN SMALL LETTER I WITH ACUTE : "ó" oacute # LATIN SMALL LETTER O WITH ACUTE : "ú" uacute # LATIN SMALL LETTER U WITH ACUTE : "ý" yacute # LATIN SMALL LETTER Y WITH ACUTE : "Ć" U0106 # LATIN CAPITAL LETTER C WITH ACUTE : "ć" U0107 # LATIN SMALL LETTER C WITH ACUTE : "Ĺ" U0139 # LATIN CAPITAL LETTER L WITH ACUTE : "ĺ" U013A # LATIN SMALL LETTER L WITH ACUTE : "Ń" U0143 # LATIN CAPITAL LETTER N WITH ACUTE : "ń" U0144 # LATIN SMALL LETTER N WITH ACUTE : "Ŕ" U0154 # LATIN CAPITAL LETTER R WITH ACUTE : "ŕ" U0155 # LATIN SMALL LETTER R WITH ACUTE : "Ś" U015A # LATIN CAPITAL LETTER S WITH ACUTE : "ś" U015B # LATIN SMALL LETTER S WITH ACUTE : "Ź" U0179 # LATIN CAPITAL LETTER Z WITH ACUTE : "ź" U017A # LATIN SMALL LETTER Z WITH ACUTE > Cheers, > Julien > ___ > xorg-devel@lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: http://lists.x.org/mailman/listinfo/xorg-devel diff --git a/nls/en_US.UTF-8/Compose.pre b/nls/en_US.UTF-8/Compose.pre index 2eae912..c9ff587 100644 --- a/nls/en_US.UTF-8/Compose.pre +++ b/nls/en_US.UTF-8/Compose.pre @@ -647,6 +647,7 @@ XCOMM Part 3 : "Ã" Oacute # LATIN CAPITAL LETTER O WITH ACUTE : "Ã" Oacute # LATIN CAPITAL LETTER O WITH ACUTE : "Ã" Oacute # LATIN CAPITAL LETTER O WITH ACUTE + : "Ã" Oacute # LATIN CAPITAL LETTER O WITH ACUTE : "Ã" Ocircumflex # LATIN CAPITAL LETTER O WITH CIRCUMFLEX : "Ã" Ocircumflex # LATIN CAPITAL LETTER O WITH CIRCUMFLEX : "Ã" Ocircumflex # LATIN CAPITAL LETTER O WITH CIRCUMFLEX @@ -772,6 +773,7 @@ XCOMM Part 3 : "ó" oacute # LATIN SMALL LETTER O WITH ACUTE : "ó" oacute # LATIN SMALL LETTER O WITH ACUTE : "ó" oacute # LATIN SMALL LETTER O WITH ACUTE + : "ó" oacute # LATIN SMALL LETTER O WITH ACUTE : "ô" ocircumflex # LATIN SMALL LETTER O WITH CIRCUMFLEX : "ô" ocircumflex # LATIN SMALL LETTER O WITH CIRCUMFLEX : "ô" ocircumflex # LATIN SMALL LETTER O WITH CIRCUMFLEX @@ -1458,7 +1460,6 @@ XCOMM Part 3 : "Ǻ" U01FA # LATIN CAPITAL LETTER A WITH RING ABOVE AND ACUTE : "Ǻ" U01FA # LATIN CAPITAL LETTER A WITH RING ABOVE AND ACUTE : "Ǻ" U01FA # LATIN CAPITAL LETTER A WITH RING ABOVE AND ACUTE - : "Ǻ" U01FA # LATIN CAPITAL LETTER A WITH RING ABOVE AND ACUTE : "Ǻ" U01FA # LATIN CAPITAL LETTER A WITH RING ABOVE AND ACUTE : "Ç»" U01FB # LATIN SMALL LETTER A WITH RING ABOVE AND ACUTE : "Ç»" U01FB # LATIN SMALL LETTER A WITH RING ABOVE AND ACUTE @@ -1467,7 +1468,6 @@ XCOMM Part 3 : "Ç»" U01FB # LATIN SMALL LETTER A WITH RING ABOVE AND ACUTE : "Ç»" U01FB # LATIN SMALL LETTER A WITH RING ABOVE AND ACUTE : "Ç»" U01FB # LATIN SMALL LETTER A WITH RING ABOVE AND ACUTE - : "Ç»" U01FB # LATIN SMALL LETTER A WITH RING ABOVE AND ACUTE : "Ç»" U01FB # LATIN SMALL LETTER A WITH RING ABOVE AND ACUTE : "Ǽ" U01FC # LATIN CAPITAL LETTER AE WITH ACUTE : "Ǽ" U01FC # LATIN CAPITAL LETTER AE WITH ACUTE ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: libX11: Changes to 'master'
On 2012-03-20 19:02, Daniel Stone wrote: > Hi, > > On 20 March 2012 17:55, Pander wrote: >> On 2012-03-20 16:41, Julien Cristau wrote: >>> Then let's make it consistent by only having one of the orders for new >>> sequences. Over time people will get the order that actually works in >>> muscle memory, we won't have so many duplicate sequences that make it >>> impossible to ever add new ones for new symbols, everyone wins. >> >> I completely agree on this policy for new series of sequences. >> >> [...] >> >> Since this concerns an existing conflict and not a new sequence, I hope >> you see the international value of resolving this to map >> to ó. This will result truly in a win-win situatión with >> the same compose sequences for all users of X, including GNOME. > > I completely agree; I'm struggling to think of a single use for å with > a combining acute accent, whereas ó is a character people actually > use. A lot. > > Cheers, > Daniel Thanks. And alternative sequnces to create å with a combining acute accent remain in tact. James, Julien, did you receive enough compelling arguments to resolve this conflict so that results in ó. Then we can finally close the book on gtk+/GNOME conflicts. Best regards, Pander > ___ > xorg-devel@lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: http://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: libX11: Changes to 'master'
On 2012-03-20 16:41, Julien Cristau wrote: > On Mon, Mar 19, 2012 at 23:03:44 +0100, Pander wrote: > >> However for ó I beg to differ. The vowels aeiou and diacritics `´'~^¯¨ >> are completely available in both orders. Because the are used so often, >> missing out on will break the consistency in this >> series and decrease user experience and expectency of the system. >> > Then let's make it consistent by only having one of the orders for new > sequences. Over time people will get the order that actually works in > muscle memory, we won't have so many duplicate sequences that make it > impossible to ever add new ones for new symbols, everyone wins. I completely agree on this policy for new series of sequences. Note that it is not only a case of muscle memory. In languages such as Danish, Dutch, German, French, Spanish, etc. one speaks and thinks in terms of ``e with an acute accent'' or ``o with an acute accent'' so it easy and intuitive to type the same order in the compose sequence. Also, some people are not quick in learning sequences so they can easily reconstruct the order from how they hear or say the combination. That is why these series for these four often used diacritics of '`^" in many languages have been created in the first place and used widely by the large user base of GNOME. These are all very regular diacritics. It was not an easy task to consolidate the almost 400 exceptions and additions made in 2008 by gtk+. Now gtk+ can use a direct download Compose.pre from X.org and finally delete gtk-compose-lookaside.txt which was causing conflicts. Since this concerns an existing conflict and not a new sequence, I hope you see the international value of resolving this to map to ó. This will result truly in a win-win situatión with the same compose sequences for all users of X, including GNOME. Regards, Pander > Cheers, > Julien > ___ > xorg-devel@lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: http://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: libX11: Changes to 'master'
On 2012-03-19 23:03, Pander wrote: > On 2012-03-19 18:45, Julien Cristau wrote: >> On Mon, Mar 19, 2012 at 16:32:07 +0100, Pander wrote: >> >>> On 2012-03-14 22:25, James Cloos wrote: >>>> Nuts. I thought all of those were sorted already. >>>> >>>> The dstroke and Dstroke lines are arguably better than the U0110 and >>>> U0111 lines. >>>> >>>> Since and were already there, >>>> theentry for ó will have to go. >>> >>> Double nuts about the apostrophe. The for ó is used >>> much much more then the sequences starting with for Ǻ >>> and ǻ, for which alternative exist. >>> >>> Please remove: >>>: "Ǻ" U01FA # LATIN CAPITAL LETTER >>> A WITH RING ABOVE AND ACUTE >>> and remove: >>>: "ǻ" U01FB # LATIN SMALL LETTER A >>> WITH RING ABOVE AND ACUTE >>> >>> because these are also available as: >>> : "Ǻ" U01FA # LATIN CAPITAL >>> LETTER A WITH RING ABOVE AND ACUTE >>> and as: >>> : "ǻ" U01FB # LATIN SMALL >>> LETTER A WITH RING ABOVE AND ACUTE >>> >>> And at the same time, restore: >>>: "Ó" Oacute # LATIN CAPITAL >>> LETTER O WITH ACUTE >>> and restore: >>>: "ó" oacute # LATIN SMALL >>> LETTER O WITH ACUTE >>> >>> There has been many requests about mirrored availability of compose key >>> sequences for often used diacritics with vowels in the past. This is >> >> Where? > > Hi Julien, > > At least in the gtk+/GNOME realm, that is probably also why both orders > are supported. If you want I can get you the URLs. Apart from that, > please see my motivation below. > >>> because, depending on their your native language, people use >>> diacritic+vowel or the reverse, vowel+diacritic. >>> >>> Sorry for the late reply but this will prevent many irritations. >>> Implementing the above mentioned change will make the overall patch from >>> downstream gtk+ a success. >>> >> Sorry, I don't think adding more redundant compose sequences qualifies >> as a success. Changing existing compose sequences to add different >> redundant ones even less so. > > I agree complete with you by not adding the redunant codes for ¤¶§ etc. > That were indeed too many for simply the same rarely used character and > gtk-lookaside should drop these as well. > > However for ó I beg to differ. The vowels aeiou and diacritics `´'~^¯¨ > are completely available in both orders. Because the are used so often, > missing out on will break the consistency in this > series and decrease user experience and expectency of the system. > > Ǻ has alternative codes and is so reaerly used, it is even hard to find > examples of usage, except for side effect of wrong encoding. :S Can you > find any? Also → ó was (until last week) an existing > compose sequence, albeit conflicting with Ǻ, only, in my perspective, > the wrong compose sequence was eliminated. Via the link below you will find an illustrated overview to support my point in the pink square. Additional requests would be in the red squares. http://img40.imageshack.us/img40/2217/mirroredvowelseries.png Other points of interest, but no that effect me personally, are the blue squares on other missing sequences and orange squares on inconsistent sequences. Note the arrow in the corners of the overview which indicate the order of the lookup of sequences. > Perhaps some other members of the community would like to support this > cause or comment on this? > >> Cheers, >> Julien > > Best regards, > > Pander > ___ > xorg-devel@lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: http://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: libX11: Changes to 'master'
On 2012-03-19 18:45, Julien Cristau wrote: > On Mon, Mar 19, 2012 at 16:32:07 +0100, Pander wrote: > >> On 2012-03-14 22:25, James Cloos wrote: >>> Nuts. I thought all of those were sorted already. >>> >>> The dstroke and Dstroke lines are arguably better than the U0110 and >>> U0111 lines. >>> >>> Since and were already there, >>> theentry for ó will have to go. >> >> Double nuts about the apostrophe. The for ó is used >> much much more then the sequences starting with for Ǻ >> and ǻ, for which alternative exist. >> >> Please remove: >> : "Ǻ" U01FA # LATIN CAPITAL LETTER >> A WITH RING ABOVE AND ACUTE >> and remove: >> : "ǻ" U01FB # LATIN SMALL LETTER A >> WITH RING ABOVE AND ACUTE >> >> because these are also available as: >> : "Ǻ" U01FA # LATIN CAPITAL >> LETTER A WITH RING ABOVE AND ACUTE >> and as: >> : "ǻ" U01FB # LATIN SMALL >> LETTER A WITH RING ABOVE AND ACUTE >> >> And at the same time, restore: >>: "Ó" Oacute # LATIN CAPITAL >> LETTER O WITH ACUTE >> and restore: >>: "ó" oacute # LATIN SMALL >> LETTER O WITH ACUTE >> >> There has been many requests about mirrored availability of compose key >> sequences for often used diacritics with vowels in the past. This is > > Where? Hi Julien, At least in the gtk+/GNOME realm, that is probably also why both orders are supported. If you want I can get you the URLs. Apart from that, please see my motivation below. >> because, depending on their your native language, people use >> diacritic+vowel or the reverse, vowel+diacritic. >> >> Sorry for the late reply but this will prevent many irritations. >> Implementing the above mentioned change will make the overall patch from >> downstream gtk+ a success. >> > Sorry, I don't think adding more redundant compose sequences qualifies > as a success. Changing existing compose sequences to add different > redundant ones even less so. I agree complete with you by not adding the redunant codes for ¤¶§ etc. That were indeed too many for simply the same rarely used character and gtk-lookaside should drop these as well. However for ó I beg to differ. The vowels aeiou and diacritics `´'~^¯¨ are completely available in both orders. Because the are used so often, missing out on will break the consistency in this series and decrease user experience and expectency of the system. Ǻ has alternative codes and is so reaerly used, it is even hard to find examples of usage, except for side effect of wrong encoding. :S Can you find any? Also → ó was (until last week) an existing compose sequence, albeit conflicting with Ǻ, only, in my perspective, the wrong compose sequence was eliminated. Perhaps some other members of the community would like to support this cause or comment on this? > Cheers, > Julien Best regards, Pander ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: libX11: Changes to 'master'
On 2012-03-14 22:25, James Cloos wrote: > Nuts. I thought all of those were sorted already. > > The dstroke and Dstroke lines are arguably better than the U0110 and > U0111 lines. > > Since and were already there, > theentry for ó will have to go. Double nuts about the apostrophe. The for ó is used much much more then the sequences starting with for Ǻ and ǻ, for which alternative exist. Please remove: : "Ǻ" U01FA # LATIN CAPITAL LETTER A WITH RING ABOVE AND ACUTE and remove: : "ǻ" U01FB # LATIN SMALL LETTER A WITH RING ABOVE AND ACUTE because these are also available as: : "Ǻ" U01FA # LATIN CAPITAL LETTER A WITH RING ABOVE AND ACUTE and as: : "ǻ" U01FB # LATIN SMALL LETTER A WITH RING ABOVE AND ACUTE And at the same time, restore: : "Ó" Oacute # LATIN CAPITAL LETTER O WITH ACUTE and restore: : "ó" oacute # LATIN SMALL LETTER O WITH ACUTE There has been many requests about mirrored availability of compose key sequences for often used diacritics with vowels in the past. This is because, depending on their your native language, people use diacritic+vowel or the reverse, vowel+diacritic. Sorry for the late reply but this will prevent many irritations. Implementing the above mentioned change will make the overall patch from downstream gtk+ a success. > So I'll push this: > > diff --git a/nls/en_US.UTF-8/Compose.pre b/nls/en_US.UTF-8/Compose.pre > index 1f72ae2..2eae912 100644 > --- a/nls/en_US.UTF-8/Compose.pre > +++ b/nls/en_US.UTF-8/Compose.pre > @@ -650 +649,0 @@ XCOMM Part 3 > - : "Ó" Oacute # LATIN CAPITAL LETTER > O WITH ACUTE > @@ -776 +774,0 @@ XCOMM Part 3 > - : "ó" oacute # LATIN SMALL LETTER O > WITH ACUTE > @@ -881,6 +878,0 @@ XCOMM Part 3 > - : "Đ" U0110 # LATIN CAPITAL LETTER > D WITH STROKE > - : "Đ" U0110 # LATIN CAPITAL LETTER > D WITH STROKE > - : "Đ" U0110 # LATIN CAPITAL LETTER > D WITH STROKE > - : "đ" U0111 # LATIN SMALL LETTER D > WITH STROKE > - : "đ" U0111 # LATIN SMALL LETTER D > WITH STROKE > - : "đ" U0111 # LATIN SMALL LETTER D > WITH STROKE > > -JimC ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Housekeeping on Compose.pre
Hi all, Thanks for submitting the patch with compose key sequences from gtk+. However, still some housekeeping needs to be done on several irregularities and errors in Compose.pre. These are listed by running this new version of check.py, see http://pastebin.com/AmqxYPn5 Regards, Pander ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Review compose key sequence patches January 3rd and 6th
On 2012-02-22 17:32, Pander wrote: > On 2012-02-22 16:31, Alan Coopersmith wrote: >> On 02/22/12 03:12 AM, Pander wrote: >>> On 2012-02-22 01:26, James Cloos wrote: >>>> [Did I already send a review?] >>> >>> No not yet. Thanks for following up on this. >>> >>>> >>>> Some initial thoughts: >>>> >>>>> + <0> : "©" copyright # >>>>> COPYRIGHT SIGN >>>> >>>> Is it really useful to use<0> (zero) for that when (majuscule oh) >>>> and (miniscule oh) are already there? >>> >>> This allows users to enter copyright sign without using SHIFT. <0> >>> of<0>would be the fastest way to enter this sign which is used >>> regularly. This also applies to the next less often used signs. >> >> How is that any faster or less involving of the shift key than >> the current? >> > > Indeed not faster than that one. It is an alternative way, which is as > fast but also possible in reverse order, which the is not. > > The compose key sequences with <0> (zero) for §, ¤ and © originate from > gtk-compose-lookaside.txt which is being maintained by Simos Xenitellis. > > Simon, can you give additional justification for the following 12 lines: > > + <0> : "©" copyright # COPYRIGHT SIGN > + <0> : "©" copyright # COPYRIGHT SIGN > + <0> : "©" copyright # COPYRIGHT SIGN > + <0> : "©" copyright # COPYRIGHT SIGN > + <0> : "§" section # SECTION SIGN > + <0> : "§" section # SECTION SIGN > + <0> : "§" section # SECTION SIGN > + <0> : "§" section # SECTION SIGN > + <0> : "¤" currency # CURRENCY SIGN > + <0> : "¤" currency # CURRENCY SIGN > + <0> : "¤" currency # CURRENCY SIGN > + <0> : "¤" currency # CURRENCY SIGN > > Or are you willing to drop them from gtk-compose-lookaside.txt? > > Note that §, ¤ and © already have enough exiting compose key sequences > and the ones under consideration are not the most obvious sequences for > these characters. In case of dropping them from > gtk-compose-lookaside.txt they will also be dropped from my > X-GTK-consolidation patch. > > Regards, > > Pander > > PS I have made a simple Python script that used while preparing the > patch for finding inconsistencies in Compose.pre. You can find it here > http://pastebin.com/5nzQK8n4 and you will see the number of warnings and > errors drop by applying the patch. A new patch for final review has been submitted here: https://bugs.freedesktop.org/show_bug.cgi?id=18751 The 10 lines which were labelled as not needed have been removed. The new patch has been made against git head of 2012-03-02. Please do a final review this patch and the patch: https://bugs.freedesktop.org/show_bug.cgi?id=44312 on which were no comments. Again, this will eliminate much of the differences between GTK and X11 compose key sequences which is long overdue. Please contact me if I can be of any assistance. Regards, Pander > ___ > xorg-devel@lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: http://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Review compose key sequence patches January 3rd and 6th
On 2012-02-22 16:31, Alan Coopersmith wrote: > On 02/22/12 03:12 AM, Pander wrote: >> On 2012-02-22 01:26, James Cloos wrote: >>> [Did I already send a review?] >> >> No not yet. Thanks for following up on this. >> >>> >>> Some initial thoughts: >>> >>>> + <0> : "©" copyright # >>>> COPYRIGHT SIGN >>> >>> Is it really useful to use<0> (zero) for that when (majuscule oh) >>> and (miniscule oh) are already there? >> >> This allows users to enter copyright sign without using SHIFT. <0> >> of<0>would be the fastest way to enter this sign which is used >> regularly. This also applies to the next less often used signs. > > How is that any faster or less involving of the shift key than > the current? > Indeed not faster than that one. It is an alternative way, which is as fast but also possible in reverse order, which the is not. The compose key sequences with <0> (zero) for §, ¤ and © originate from gtk-compose-lookaside.txt which is being maintained by Simos Xenitellis. Simon, can you give additional justification for the following 12 lines: + <0> : "©" copyright # COPYRIGHT SIGN + <0> : "©" copyright # COPYRIGHT SIGN + <0>: "©" copyright # COPYRIGHT SIGN + <0>: "©" copyright # COPYRIGHT SIGN + <0>: "§" section # SECTION SIGN + <0> : "§" section # SECTION SIGN + <0>: "§" section # SECTION SIGN + <0> : "§" section # SECTION SIGN + <0> : "¤" currency # CURRENCY SIGN + <0>: "¤" currency # CURRENCY SIGN + <0> : "¤" currency # CURRENCY SIGN + <0>: "¤" currency # CURRENCY SIGN Or are you willing to drop them from gtk-compose-lookaside.txt? Note that §, ¤ and © already have enough exiting compose key sequences and the ones under consideration are not the most obvious sequences for these characters. In case of dropping them from gtk-compose-lookaside.txt they will also be dropped from my X-GTK-consolidation patch. Regards, Pander PS I have made a simple Python script that used while preparing the patch for finding inconsistencies in Compose.pre. You can find it here http://pastebin.com/5nzQK8n4 and you will see the number of warnings and errors drop by applying the patch. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Review compose key sequence patches January 3rd and 6th
On 2012-02-22 01:26, James Cloos wrote: > [Did I already send a review?] No not yet. Thanks for following up on this. > > Some initial thoughts: > >> + <0> : "©" copyright # COPYRIGHT SIGN > > Is it really useful to use <0> (zero) for that when (majuscule oh) > and (miniscule oh) are already there? This allows users to enter copyright sign without using SHIFT. <0> of <0> would be the fastest way to enter this sign which is used regularly. This also applies to the next less often used signs. > > That also applies to § section and ¤ currency. These (©, § and ¤) originate from gtk-compose-lookaside.txt with the purpose to be merged here, upstream. They do not interfere with other schemes concerning <0> (zero). My motivation for these is to consolidate the exceptions currently defined by Simos in GTK (and GNOME) so all flavours of X will use the ones defined in Compose.pre This was also the goal of gtk-compose-lookaside.txt but that file grew over the years without merging upstream. Now it is time to start merging and hopefully get rid of it completely. > >> + : "¶" paragraph # PILCROW SIGN >> + : "¶" paragraph # PILCROW SIGN > > The logic of the current Multi_key sequences ( is > DOT BELOW for all current sequences where it preceses a letter) would > suggest that those two would be used for the strings "p̣" and "P̣". > > Goog finds hits in wikipedia¹ (representing the IPA /pʼ/ in Riggs’ and > Williamson’s orthographies for Sioux), a usage in chemical symbols and > some hits which suggest that it may be used in latin transcriptions of > one or more of the script of India. Agreed, these two need to be removed from the patch. > > > Other wise it looks good and applies. With the caveats above, > > Reviewed-by: James Cloos Thank you for the review. What are now the next steps for the patches in http://lists.x.org/archives/xorg-devel/2012-January/028253.html and http://lists.x.org/archives/xorg-devel/2012-January/028432.html Regards, Pander > > > 1] http://en.wikipedia.org/wiki/Sioux_language >http://fr.wikipedia.org/wiki/P%CC%A3 > > -JimC ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Review compose key sequence patches January 3rd and 6th
Hi all, Could someone review the patches I have submitted on the 3rd and 6th of January? http://lists.x.org/archives/xorg-devel/2012-January/028253.html and http://lists.x.org/archives/xorg-devel/2012-January/028432.html A lot of work went into the second patch so I would be pleased to hear your feedback. Thanks, Pander ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Request review libx11 compose seqeunce patch
Hi all, Please review this patch for libx11 to extend and fix compose key sequences as was request via GTK+ community a while back. The patch and extensive comment can be downloaded here: https://bugs.freedesktop.org/show_bug.cgi?id=18751#c7 Implementing this will improve overall quality of compose sequences and consolidate the 413 additional compose sequences currently defined in gtk+ for GNOME and solving conflicting definitions compared to compose sequences in Xorg for KDE, etc. A lot of work has gone in to this and I hope this bug can be solved soon. Please contact me if I need to amend something to the patch or if you have any questions. Thanks, Pander ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Request review patch compose key sequences musical symbols
Hi all, Please review attached patch to complere compose key sequences for musical symbols as is described in: https://bugs.freedesktop.org/show_bug.cgi?id=44313 Best regards, Pander diff --git a/nls/en_US.UTF-8/Compose.pre b/nls/en_US.UTF-8/Compose.pre index d5b01b1..39bd047 100644 --- a/nls/en_US.UTF-8/Compose.pre +++ b/nls/en_US.UTF-8/Compose.pre @@ -209,6 +209,10 @@ XCOMM Dashes : "â" U2014 # EM DASH XCOMM Musical alterations + : "â©" U2669 # QUARTER NOTE + : "âª" U266a # EIGHTH NOTE + : "â«" U266b # BEAMED EIGHTH NOTES + : "â¬" U266c # BEAMED SIXTEENTH NOTES : "â" U266d # MUSIC FLAT SIGN : "â®" U266e # MUSIC NATURAL SIGN : "â¯" U266f # MUSIC SHARP SIGN ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
