Re: question on armhf color depth
One thing I forgot to mention is fbturbo, I installed it and forgot
about it until I was looking in my xlog. In principle it should be
helping, in practice I'm not sure. But it hasn't caused any trouble.
It's an improved frame buffer driver.
One thing about the errors and warnings in xlog, is that to some
degree it's probing to see what hardware it's got by trying things
until they fail, then it chooses a different route. I don't have
AIGLX or DRI either.
I guess one test would be what happens when you play a video. If your
CNC stuff seems slow part of that could be computational speed,
especially if it does a lot of floating point. Framerates in videos
are often up around 25-30 frames/second.
Not that it's any wonderful test but this is what heated up my Pi
rendering frames for: http://ab1jx.1apps.com/video/pballsm.html
omxplayer should be already installed I think, it's a video/audio
player that works at low level with the Pi hardware. Sometimes it
silently refuses to show a video, supposedly that's due to a lack of
memory but it doesn't give an error message. It seems to show
everything full screen, but maybe it's manipulating part of the frame
buffer to lower resolution. It has a man page.
On 4/10/17, Gene Heskett <gheskett@shentel.net> wrote:
> On Monday 10 April 2017 04:55:39 Mark Morgan Lloyd wrote:
>
>> On 10/04/17 02:30, Alan Corey wrote:
>> > I think you can add entries to /etc/fb.modes but it's like making
>> > old-style modelines, it takes lots of information. And my old buddy
>> > xvidtune doesn't work on a Pi. But you're a tv guy.
>>
>> Video modes have been causing me a great deal of pain over the last
>> few weeks. I could say much more but will keep it short with just two
>> comments to start with:
>>
>> * Look at what's in your X log file and at
>> /sys/class/graphics/fb0/modes (should apply to most systems that use
>> standard video).
> pi@raspberrypi:~/linuxcnc $ cat /sys/class/graphics/fb0/modes
> U:1366x768p-0
> pi@raspberrypi:~/linuxcnc $
>
> From the log:
>
> [ 12.657] (WW) Falling back to old probe method for modesetting
> [ 12.657] (EE) open /dev/dri/card0: No such file or directory
> [ 12.657] (WW) Falling back to old probe method for fbdev
> --
> [ 12.780] (II) AIGLX: Screen 0 is not DRI2 capable
> [ 12.780] (EE) AIGLX: reverting to software rendering
> [ 14.243] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
>
> How can these be fixed? The video's update rate sux.
>
>> * Use tvservice to get EDID info from your screen and feed it to
>> edid-decode (systems other than RPi will have some different means of
>> getting the binary EDID block, e.g. an Odroid uses a modified U-Boot).
>>
>> It's obviously important though to distinguish between resolution/sync
>> configuration and the colour depth, the latter being largely
>> determined by available memory.
>
> And 128 megs is not enough for 32 bit apparently. It (24 bit) also slows
> rendering speed noticably.
>
> Thanks Mark.
>
> 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>
>
>
--
-------------
No, I won't call it "climate change", do you have a "reality problem"? - AB1JX
Impeach Impeach Impeach Impeach Impeach Impeach Impeach Impeach
Reply to: