Re: screenblanker vs login
On Thursday 15 February 2018 08:42:24 Stefan Monnier wrote:
> > Do they not understand that the market for their hardware would
> > expand considerably if they'd supply the info and encourage our FSF
> > aligned people to write the drivers,?
> >
> > Look at the nouveau situtation.
>
> AFAIK Nvidia doesn't understand much more than ARM does: they get as
> much in the way, but it's not like they're supportive of the
> nouveau effort.
>
> But I agree: ARM is being stupid.
But we aren't in the legal chairs at arm. Sadly...
>
> >> Other relevant information is that Mali is really just the GPU,
> >> i.e. a processor that can perform efficient computations like those
> >> used for 3D rendering. This is separate from the display engine
> >> itself (the thing that takes a framebuffer and pushes the pixels to
> >> a screen), or from the video encode/decode hardware.
> >
> > And the framebuffer is both slow, and in the case of the pi, limited
> > color depth, 5,6,5 I think as opposed to the full 8,8,8. The pi3b
> > manages about 7 frames a second for a refresh rate running jessie
> > and lxde.
>
> The framebuffer is not an alternative to a GPU: the GPU is the
> co-processor used to speed up generating images into the framebuffer,
> so if you want to see something on your screen, you'll need
> a framebuffer anyway.
>
> Think of a GPU (such as Mali) as a specialized floating-point
> co-processor. In the x86 world, the term GPU is used to refer to
> a graphics card that incorporates various elements, such as the
> display engine, the GPU per se, and the video en/decode engine. This
> is because you can't easily get them separately. In the ARM world this
> is not so: the Mali line of GPUs is just the GPU itself and is
> combined by SoC vendors with various vendor-provided display engines
> and VPUs (video processing units: the thingies that can perform
> encoding/decoding of video and audio in specialized hardware). Note
> that VPUs also are separate from the display engine: you may very well
> use a VPU on a headless machine, e.g. to re-encode a video stream
> coming from a camera before streaming it to a disk, or to re-encode a
> video stream coming from a disk and streamed to some remote client for
> display.
>
> > That does NOT give us a backplot thats in time with what the
> > machine is doing. And that can be dangerous to both the machine and
> > the operator if he gets in its way. But I do get the impression the
> > framebuffer of a rock64 is some faster.
>
> framebuffers are not faster or slower in this sense: all that they do
> is to tell you: "here is a chunk of memory which I will send to your
> HDMI/DVI/... connector at the usual 60Hz frequency".
>
> Then someone else is in charge of actually drawing something useful
> into it (and changing this something whenever needed). So, if you
> don't have a GPU to do the writing, you use the CPU, and a faster CPU
> will result in faster drawing.
>
> > Color depth I haven't checked other than to note that synaptic, with
> > its plethora of shades of white, is considerable more usable on
> > a rock64 running stretch + xfce, than it is on the pi running lxde.
>
> The color depth is specified by the framebuffer (aka display
> engine), yes. If the driver is complete you can usually control the
> color depth, the screen size (horiz x vert number of pixels), and the
> refresh rate via things like xrandr.
>
xrandr, on the pi, has zero references to color depth, and neither does
its manpage. Both pi and rock64 reports are essentially identical. But
IIRC discovering that its reporting the screen my terminal is logged in
on, as the rock says its 1920x1080. And the monitor connected has a max
of 1366x768, and that monitor has become famous around my shop for doing
a shutdown if its not getting 1366x768. P.O.S. from AOC, what can I say
other than it was cheap at Wallies. With zero mention of its fixed
resolution on the box or accompanying paper. Grrrr.
> >> So for example on Allwinner (sunxi) hardware there's recent
> >> progress on getting support for the display engine (some of it
> >> already in mainline Linux) and the video decoder (work still in
> >> progress).
> >
> > Having built the v4.14.15-rt13 kernel on the rock64, that has not or
> > is not shown in the "make menuconfig" options when the arch is set
> > for rockchip. At least not that I have tripped over.
>
> IIRC the sunxi display engine driver (sun41-drm) now (i.e. in 4.15)
> supports the A10/A20/A13 and A31(s?) CPUs. I don't know how far along
> they are w.r.t support for more recent chips.
>
> > However, I just checked the modules.builtin file in the built kernel
> > tree and found this entry: kernel/drivers/gpu/drm/arm/mali-dp.ko but
> > I've not a clue what it can do, primarily because there is not a
> > ready recipe as to how to go about changing the kernel in a u-boot
> > install. If anyone has that recipe, please share.
>
> IIUC this is the kernel side of the Mali support: thanks to the GPL
> this part of the Mali support legally has to be Free Software so it is
> distributed that way (tho AFAIK it hasn't been integrated into the
> mainline kernel because it doesn't try to integrate into the standard
> GPU infrastructure). But to make use of the Mali GPUs you need to
> couple that with a user-space driver which is only available as a blob
> (and even distributing that blob legally is sometimes problematic).
>
Spit. I do see a driver listed on vger?, but haven't downloaded it yet.
Should I?
>
Thanks Stefan
--
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
Reply to: