comparis
In-Reply-To: <18720420.1176441524614.JavaMail.Twebapp at oss-app1>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-OpenSolaris-URL:
http://www.opensolaris.org/jive/message.jspa?messageID=110163&tstart=0#110163
> wsfb does not depend on ioctl()'s (not plural), but
> only on a single problematic one (in the sense of
> being device specific) :
> $ grep -n FBIOGXINFO ./*
> wsfb_driver.c__ORIG:410: if (ioctl(fd,
> FBIOGXINFO, &fbinfo) == -1) {
> wsfb_driver.c__ORIG:525: if (ioctl(fPtr->fd,
> FBIOGXINFO, &fbinfo) == -1) {
> wsfb_driver.c__ORIG:527:
> "ioctl FBIOGXINFO: %s\n",
> if (ioctl(fPtr->fd, FBIOGXINFO,
> &fbinfo) == -1)
AlanC, a further self-correction: Those, who ever browsed through
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/sys/fbio.h#52
and
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/sys/visual_io.h
(maybe just did "#man visual_io") - plus went through wsfb_driver.c _plus_
through your three patches in the wsfb subdir
shadow-crash.patch
solaris-port.patch
wsfb-updates.patch
(Besides: wsfb-updates.patch is left alone and has [non-anonymous] git-gdiff
syntax)
Okay, so you have done a good job in adjusting wsfb_driver.c from BSD to
Solaris / to translate BSD's wsfb ioctl()'s to what Solaris' console drivers
normally offer, at least _some_ of them offer, unfortunately not all, as
FBIOGXINFO is not mandatory for such a driver (according to docs.sun.com), and
may therefore be missing in certain cases, as we saw in terms of PGX32's gfxp.
A generic driver such as wsfb should not depend on the presence of _any_single_
ioctl().
Especially not for trivial things like "how is the wheather today".
Note: Neither glint, nor even the various interacting ati-drivers depend on any
ioctl().
The nice thing with them: There you can have /dev/fb point to whatever file,
i.e. /dev/null or an empty touch-generated file.
And you can still start up X11, without getting "inappropriate ioctl()".
I dirtily got wsfb_driver.c modified to take hardwired values for
wstype (aka int default_depth)
and
fbinfo.line_bytes.
I also temporarily didabled the buggy check, if /dev/fb's default depth equals
the desired depth for X.
That way Xorg comes still up on a XVR-100 (only in 8bpp) with that wrong image
(you can see mouse movements, but the actual screen is split into 1/3rd on the
left and 2/3rds on the right.
New: The wsfb driver come almost up on a PGX32 now, but then crashes Signal 10
or Signal 12 in shadow (I see from your patch that you had similar trouble in
case of Ati as well, before you wrote shadow-crash.patch)
>
> And it wasn't m64, but pfb (ATI-Radeon_/_XVR-100) :
> bash-3.00$ strings
> /platform/sun4u/kernel/drv/sparcv9/*|grep
> FBIOGXINFO|wc -l
> 1
> 00$ strings
> /platform/sun4u/kernel/drv/sparcv9/pfb|grep
> FBIOGXINFO|wc -l
> 1
> 00$ strings
> /platform/sun4u/kernel/drv/sparcv9/pfb|grep
> FBIOGXINFO
> FBIOGXINFO
That way of dealing with it (via /bin/strings) was of course nonsense, as it
only shows those occurrences where an error message in ASCII is contained in a
binary, and it otherwise doesn't tell us very much concerning which ioctl()'s
may, or may not, be used.
### So to to conclude:
# FBIOGXINFO is not device specific per se, but some console drivers just don't
offer it
(at least one, gfxp)
# I don't see a better translation from BSD's WSDISPLAYIO_LINEBYTES to Solaris,
than FBIOGXINFO, so well done!
# we have to get rid of ioctl's for wsfb, as we have to be as generic with our
expectations, as possible
By the way: I just got my Expert-3d-Lite from my reliable dealer in Rishon Le
Zion, and I will put it into my U60 now and give wsfb and vesa and vga a try :)
Note: I still see chances for vesa_drv and vga_drv, the former says for XVR-100
"Screens found, but none have a usable configuration (I have to enable
re-debugging in aperture). Nothing useful mmap() relevant found in dmesg (which
once gave me a great hint for the sunffb).
The vga_drv even completely boots Xorg under XVR-100, detects it, if I click
the 3rd mouse button.
But the screen remains blank.
Looks like byteorder related, but semi-blindly adding -DSPARC_MMIO_IS_BE did
not help this time.
Maybe one needs to change the actual source for this, but I first need to know,
whether or not vga_drv works on Linux/BSD sparc or ppc at all.
Alan, why didn't you just correct me where I made wrong wsfb_drv related
_guesses_ that night?
My workplace is very chaotic at times, and I may make many mistakes.
But I'm not working from theory books (which I all have in my shelf, including
Solaris Internal_II, SystemsProgramming and
SPARC_Architecture_Assemply_Language_Programming_and_C_1rst_and_2nd_Editions
etc. etc. etc) to some potential goal, but - sometimes in a hurry, without too
many thoughts - the other way around.
Life is just too short for reading all the books that I'm interested in from A
to Z first (I have at least 30Thousand most important pages waiting for me).
So it is a patchwork sometimes.
This message posted from opensolaris.org
