Looks like there was a typo in the third patch’s message: s/This patches/This patch/
> On Jan 30, 2021, at 20:31, Lev via cdesktopenv-devel > <cdesktopenv-devel@lists.sourceforge.net> wrote: > > Hi Jon, > >> On Jan 30, 2021, at 18:11, Jon Trulson <j...@radscan.com> wrote: >> >> On 1/26/21 9:23 PM, Lev wrote: >>> Hi Jon and Chase, >>> >>> >>> >>>> On Jan 26, 2021, at 18:56, Jon Trulson <j...@radscan.com> >>>> wrote: >>>> >>>> On 1/25/21 8:54 PM, Lev wrote: >>>> >>>>> Hi Jon, >>>>> >>>>> Thank you for committing that, it should be the last ksh93 patch. Did you >>>>> get a chance to look at the other five patches I sent on 17th? I don’t >>>>> believe they are in yet. >>>>> >>>>> >>>> I must have missed them... I remember skipping some of them because I had >>>> already applied them. If I look at the log in master, there are several >>>> patched from you regarding musl... >>>> >>>> If there are some I missed (possible since some of them were embedded in >>>> threads), re-send them (minus any ksh stuff) and I'll merge them. >>>> >>> Thanks, I’ve attached the (rebased) patches. >>> >> >> Hi Lev, I have merged these into master - however I rewrote the commit >> messages somewhat. > > Thanks, I appreciate it. I have some additional patches. The first is an > AArch64 fix that resolves ticket 102 according to the reporter. The other two > are to revamp CDE’s internationalization support. > >> As a general rule, a 'proper' git commit message should have a short (no >> more than 70-ish characters) first line, then a blank line, and then any >> further details that you think are relevant, with lines not exceeding 70-ish >> characters... >> >> What is not quite proper IMO are single sentences exceeding 200 characters >> :) In fact, no line should exceed 80 characters for old-skool (and >> formatting, release notes, etc) reasons... >> >> So I hope you do not mind. Please look at the re-wording I did - this will >> give you an idea of what I generally prefer - the content is yours however. >> This is just a request, not a law. >> >> Just please no more 80+ character single-sentence commit lines :) >> > > Duly noted. May I have permission to edit the contributing to CDE section to > add this as a style guideline? Also, if I can get CDE building on the > historic platforms during my next break, could I please add a link under that > section? > >> >>> Sorry to hear that. Did anything survive regarding its architecture? I >>> remember it required a kernel module, but I can’t remember the reason why >>> instead of writing to the card’s framebuffer in /dev/mem. I wonder if X11 >>> could have taken a different path, and I imagine you have a unique >>> knowledge of the history behind the X Consortium, XFree86, and the >>> rebranding/merger of X.org. As a software engineer, did you have any >>> impressions/opinions regarding XIE, STSF, and Display Postscript? XRender >>> and Xft do not really seem to mesh well with X11’s client-server >>> architecture. >>> >> >> Somewhat off-topic, but... :) >> >> No, it's architecture does not exist in the wild. The kernel driver was >> 'xsvc' or the X-Services module. It was developed on Solaris first as it >> was the only way to access certain hardware resources we needed, like memory >> mapped registers, allocation of contiguous physical DMA regions, etc. >> >> It became required on Linux and the other OS's we supported at the time that >> AGP became a thing along with memory mapped registers over PCI (as opposed >> to port IO instructions) in more modern chipsets/cards, and then need for >> physically contiguous memory for DMA - vital to having the performance needs >> for decent OpenGL 3D (and 2D). >> >> Unfortunately you do not communicate with GPU's by just writing pixels to >> the FB. Acceleration means talking to another processor(s) essentially and >> feeding it commands - via DMA for performance reasons. Preferably in a very >> fast and efficient manner. >> >> So, via xsvc, most of our acceleration logic was in userspace. Pro's and >> cons about that. The current Linuxen (and maybe others now) use DRM/DRI >> (aside from NVidia and maybe AMD?). >> >> This keeps most of that logic (at least validation) in kernel modules. It >> was an approach we (XiG) considered at the time, but developing and >> supporting complex custom kernel modules for various operating systems and >> graphics HW combinations (think HP-UX, AIX, etc) was not desired. Xsvc was >> an enabler -- as ignorant as possible about the actual HW -- with very few >> exceptions like AGP chipsets and some cards that required interrupt handling. >> >> Funny thing, the Engineering manager at the time left the company not long >> after I started, and along with Brian Paul (Mesa god) and others started >> Tungsten Graphics, where they pushed DRI/DRM. Even though Tungsten doesn't >> exist anymore either (I don't think) DRI/DRM still lives on -- it won :) >> >> Anyway, a nice little trip down history lane :D >> >> -jon > > Thanks for the overview, that’s really interesting. The last time I did > direct work with a graphics card, I was programming CRTC parameters, and > things were much simpler :) If I understand correctly that Xsvc was designed > to be an compact, ultra-portable kernel to userspace accelerator adapter, was > context switching the major drawback? Perhaps once there’s no more commercial > interest, they’ll open the code. I know the BSD’s have a very hard time > continually porting Linux’s DRM stack, and I can also see the advantage for > systems where you don’t have access to the kernel source code. > > Kind regards, > Lev > <0001-config-cf-Imake.cf-Define-AArch64Architecture-on-the.patch><0002-Rename-the-CATGETS-macro-to-MCATGETS.patch><0003-Centralize-catgets-calls-through-MsgCat.patch> > > >> >>> Kind regards, >>> Lev >>> >>> >>>>> Kind regards, >>>>> Lev >>>>> >>>>> >>>>> >>>>>> On Jan 23, 2021, at 17:11, Jon Trulson <j...@radscan.com> >>>>>> >>>>>> wrote: >>>>>> >>>>>> On 1/18/21 8:21 AM, Lev via cdesktopenv-devel wrote: >>>>>> >>>>>> >>>>>>> Here’s a revised copy of the ksh fixes I submitted before that properly >>>>>>> tests for POSIX-compliant terminal handling capabilities rather than >>>>>>> attempting to get OLDTERMIO working. I think these patches are ready to >>>>>>> be committed. >>>>>>> >>>>>>> >>>>>>> >>>>>> Sorry I missed this one. I've added it to master. However, I think any >>>>>> future ksh changes should go to the ksh93 maintainer... I'd like to get >>>>>> Chase's ksh tree merged to master soon... >>>>>> >>>>>> Thanks! >>>>>> >>>>>> -jon >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Kind regards, >>>>>>> Lev >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Jan 17, 2021, at 19:17, Lev via cdesktopenv-devel >>>>>>>> <cdesktopenv-devel@lists.sourceforge.net> >>>>>>>> >>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I am now able to compile CDE on Void PPC with musl. In the future, it >>>>>>>> might make sense to create a PpcLeArchitecture for Alpine Linux (also >>>>>>>> using musl) for CI with a minimal image. >>>>>>>> >>>>>>>> Kind regards, >>>>>>>> Lev >>>>>>>> >>>>>>>> <0001-Fix-warnings-on-PowerPC-builds-and-correct-a-compile.patch><0002-The-musl-C-library-does-not-define-MAXNAMLEN-but-we-.patch><0003-The-musl-C-library-requires-the-inclusion-of-the-SVR.patch><0004-Include-config.h-for-the-definition-of-u_int.-Proper.patch><0005-Disable-binding-a-privileged-client-port-with-rresvp.patch>_______________________________________________ >>>>>>>> cdesktopenv-devel mailing list >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> cdesktopenv-devel@lists.sourceforge.net >>>>>>>> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel >>>>>>> _______________________________________________ >>>>>>> cdesktopenv-devel mailing list >>>>>>> >>>>>>> >>>>>>> >>>>>>> cdesktopenv-devel@lists.sourceforge.net >>>>>>> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel >>>>>> -- >>>>>> Jon Trulson >>>>>> >>>>>> "Entropy. It isn't what it used to be." >>>>>> -- Sheldon >>>>>> >>>>>> _______________________________________________ >>>>>> cdesktopenv-devel mailing list >>>>>> >>>>>> >>>>>> cdesktopenv-devel@lists.sourceforge.net >>>>>> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel >>>> -- >>>> Jon Trulson >>>> >>>> "Entropy. It isn't what it used to be." >>>> -- Sheldon >>>> >>>> >> >> -- >> Jon Trulson >> >> "Entropy. It isn't what it used to be." >> -- Sheldon >> > > _______________________________________________ > cdesktopenv-devel mailing list > cdesktopenv-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel _______________________________________________ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
