[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

[Мартин Бохниг]

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
191

root at opensxce:~# nm /mnt11.0/platform/i86pc/kernel/misc/amd64/gfx_private|wc -l
283

root at opensxce:~# nm /mnt11.1/platform/i86pc/kernel/misc/amd64/gfx_private|wc -l
271

root at opensxce:~# nm /mnt11.2/platform/i86pc/kernel/misc/amd64/gfx_private|wc -l
301

root at opensxce:~# nm /mnt11.3/platform/i86pc/kernel/misc/amd64/gfx_private|wc -l
301



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
 * case.
 */


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...
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20151214/35bb543d/attachment.html>