[oi-dev] [OpenIndiana-discuss] Sun/Oracle China's DRM//KMS Sol11.2 port backported to function on old-style gfxp_private from pre-2010 era but still immediatedly PANICS
opensxce at mail.ru
Mon Dec 14 20:44:57 UTC 2015
randyf at sibernet.com randyf at sibernet.com
Tue Dec 1 06:44:23 UTC 2015
> For a long time I had wished that somebody at Sun/Oracle might give as a view
> at their modern gfxp implementation, which has proven to be a highly moving
> target (unfortunately only since after the closing of OS/Net).
It's not as moving as you might think. A number of things were added
late in S11 to support non-intel framebuffers, it just seemed proper to
have i915 use them where appropriate. Though not sure yet what might
venture into the next version.
No? Are you sure?
I don't "think", I simply checked the FACTS:
root at opensxce:~# mount -F ufs -o ro,nologging /oi-dev-151a8ba /mnt_oi-dev-151a8ba
root at opensxce:~# mount -F ufs -o ro,nologging /bas11.0 /mnt11.0
root at opensxce:~# mount -F ufs -o ro,nologging /bas11.1 /mnt11.1
root at opensxce:~# mount -F ufs -o ro,nologging /bas11.2 /mnt11.2
root at opensxce:~# mount -F ufs -o ro,nologging /bas11.3 /mnt11.3
nm /mnt_oi-dev-151a8ba/platform/i86pc/kernel/misc/amd64/gfx_private|wc -l
root at opensxce:~# nm /mnt11.0/platform/i86pc/kernel/misc/amd64/gfx_private|wc -l
root at opensxce:~# nm /mnt11.1/platform/i86pc/kernel/misc/amd64/gfx_private|wc -l
root at opensxce:~# nm /mnt11.2/platform/i86pc/kernel/misc/amd64/gfx_private|wc -l
root at opensxce:~# nm /mnt11.3/platform/i86pc/kernel/misc/amd64/gfx_private|wc -l
Then in Solaris11.3's header /usr/include/sys/gfx_private.h we can read:
* For drivers to register support routines.
* blt, copy and clear are for hardware accelerated operations, while setmode
* is for driver supported setting and restore of graphics modes. setmode
* receives as a parameter all the valid parameters for KDSETMODE ioctl, like
* KD_TEXT and KD_GRAPHICS.
* Drivers should return GFXP_SUCCESS on success and GFXP_FAILURE on failure.
* On failure we do a best effort to try performing the operation with
* 'generic routines' (see gfxp_bitmap.c).
* NOTE: drivers should use this callback method instead of handling the ioctl
* without passing it up, because we might have to perform more operations
* on behalf of the ioctl request. With the exception of setmode, all the other
* routines can get called in polled I/O mode, with all the restriction of the
This mentioned src file gfxp_bitmap.c does not exist _at_all_ in Illumos / old time OpenSolaris.
Judging from the number of new symbols added the the end binary this file must be at least 1000 (thousand!) lines or longer.
But all clear - gfx_private is "not a moving target".
We can compare the situation to MS-DOS vs. WfW3.11.
WfW3.11 (Sun China's DRM/GEM/KMS port) has now been published as src. Hooray!
But it demands that we are at least on MS-DOS 5.00 (gfx_private from Sol11.1 or higher).
We - however - are still on MS-DOS 3.x here (Illumos' basic gfx_private, not doing essential mmap()ings).
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).
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the oi-dev