<HTML><BODY><br>randyf at sibernet.com randyf at sibernet.com<br>Tue Dec 1 06:44:23 UTC 2015<br>><br>> For a long time I had wished that somebody at Sun/Oracle might give as a view <br>> at their modern gfxp implementation, which has proven to be a highly moving <br>> target (unfortunately only since after the closing of OS/Net).<br><br> It's not as moving as you might think. A number of things were added <br>late in S11 to support non-intel framebuffers, it just seemed proper to <br>have i915 use them where appropriate. Though not sure yet what might <br>venture into the next version.<br><br><br><br>No? Are you sure?<br>I don't "think", I simply checked the FACTS:<br><br><br>root@opensxce:~# mount -F ufs -o ro,nologging /oi-dev-151a8ba /mnt_oi-dev-151a8ba<br>root@opensxce:~# mount -F ufs -o ro,nologging /bas11.0 /mnt11.0<br>root@opensxce:~# mount -F ufs -o ro,nologging /bas11.1 /mnt11.1<br>root@opensxce:~# mount -F ufs -o ro,nologging /bas11.2 /mnt11.2<br>root@opensxce:~# mount -F ufs -o ro,nologging /bas11.3 /mnt11.3<br><br><br><br>nm /mnt_oi-dev-151a8ba/platform/i86pc/kernel/misc/amd64/gfx_private|wc -l<br>191<br><br>root@opensxce:~# nm /mnt11.0/platform/i86pc/kernel/misc/amd64/gfx_private|wc -l<br>283<br><br>root@opensxce:~# nm /mnt11.1/platform/i86pc/kernel/misc/amd64/gfx_private|wc -l<br>271<br><br>root@opensxce:~# nm /mnt11.2/platform/i86pc/kernel/misc/amd64/gfx_private|wc -l<br>301<br><br>root@opensxce:~# nm /mnt11.3/platform/i86pc/kernel/misc/amd64/gfx_private|wc -l<br>301<br><br><br><br>Then in Solaris11.3's header /usr/include/sys/gfx_private.h we can read:<br>/*<br> * For drivers to register support routines.<br> *<br> * blt, copy and clear are for hardware accelerated operations, while setmode<br> * is for driver supported setting and restore of graphics modes. setmode<br> * receives as a parameter all the valid parameters for KDSETMODE ioctl, like<br> * KD_TEXT and KD_GRAPHICS.<br> *<br> * Drivers should return GFXP_SUCCESS on success and GFXP_FAILURE on failure.<br> * On failure we do a best effort to try performing the operation with<br> * 'generic routines' (see gfxp_bitmap.c).<br> *<br> * NOTE: drivers should use this callback method instead of handling the ioctl<br> * without passing it up, because we might have to perform more operations<br> * on behalf of the ioctl request. With the exception of setmode, all the other<br> * routines can get called in polled I/O mode, with all the restriction of the<br> * case.<br> */<br><br><br>This mentioned src file gfxp_bitmap.c does not exist _at_all_ in Illumos / old time OpenSolaris.<br>Judging from the number of new symbols added the the end binary this file must be at least 1000 (thousand!) lines or longer.<br>But all clear - gfx_private is "not a moving target".<br><br>We can compare the situation to MS-DOS vs. WfW3.11.<br>WfW3.11 (Sun China's DRM/GEM/KMS port) has now been published as src. Hooray!<br>But it demands that we are at least on MS-DOS 5.00 (gfx_private from Sol11.1 or higher).<br>We - however - are still on MS-DOS 3.x here (Illumos' basic gfx_private, not doing essential mmap()ings).<br><br>If somebody at Sun really (!) wants to see the community getting Intel-KMS to work with Sun China's port, then gfx_private also belongs into the X11 gate (the two are glued together like MS-DOS 7.0 and 7.10A and 8.00 to their Win4.00, 4.10 and 4.90 shell counterparts).<br>If this won'te happen, I must do what I hoped I wouldn't need: Messing years long with my own 2013/2014 port, which I tried to port over from OpenBSD with huge unimaginable (!) amounts of time and work, yet only some limited mini-success.<br><br></BODY></HTML>