On Monday 10 April 2017 07:21:45 Mark Morgan Lloyd wrote: > On 10/04/17 10:30, Gene Heskett 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. > > You'll need to check with somebody who knows the specific RPi/Raspbian > situation. I suspect it will require non-free drivers... and that's > non-free as in beer as well as speech. > > >> * 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. > > Stop flailing around and get the EDID info to see what refresh rate > the screen will offer for any given resolution. Then start off at 16 > bits, try to get that working, and then try 24. > > The best I can get at 3840x2160 (?) is 24 fps from an RPi3. 16 bit > video is OK, 24-bits is marginal (I suspect a problem with mouse > pointer etc. code), 32 bits has a major impact on system stability > (i.e. length of time it will run before it's using swap). HDMI is > designed around a 24-bit data stream and I don't know to what extent > trying to use 32 confers any advantage, and there's some unpleasant > maximum pixel rates etc. to contend with. In principle it should be > possible to tune the RPi modeline to emit sync rates etc. that don't > exceed the limitations of the clock rate, in practice we've had no > success with that yet but I'm still to start playing with full > modelines... note that modeline format is not the classic XFree86 one. > > In practical terms the video capabilities of an Odroid C2 are > substantially better, even if their Ubuntu-derived UI sucks and > they've got package dependency problems. I'll nominate that for the basic truth of the month. I have a c2, and its video IS better, but they've never built an rt-preempt kernel, which is the minimum it takes to run LinuxCNC. And AFAIK, there has never been a usable spi driver written for it. When I go on their forum and ask about those 2 items, I'm either ignored or told to sod off. The SPI driver for the pi that one of the fellows on the LinuxCNC mailing list wrote, runs at 32 megabits/second, talks in 4 byte packets, and talks to a fpga based i/o card with 72 control lines, the first 30 or so can be made into fixed functions by loading the correct firmware into with the mesaflash utility. Those i/o pins not used become programable gpio pins. That interface card can be programmed for either an EPP parport comm channel, or the SPI, which is even faster. And this i/o card is relatively cheap at $62. But its all 3.3 volt internally, with a 5 volt tolerance, and easily destroyed, so I have ordered a box to put the pi and the 7i90 in so I can separate the i/o from the motor drivers noises, which can exceed 20 volts of induced noise at frequencies of 100MHz or more. So line by line I am cobbling up filters and voltage clippers. When finished, I'll have the drivers and all their noise in one closed box, and the r-pi-3b and interface in a separate box just as well sealed. And I have a wrist strap I put on before touching it as its backed up close to the garage door, which has been retro-fitted with an additional 2" of blue styro, If my butt slides along that stuff for 2 or 3 inches, I'm up to several thousand volts, and can blow such stuff up instantly. Wrist strap mandatory IOW. > I don't know to what extent > that indicates an inherent superiority of the Odroid's Mali graphics > subsystem over the RPi's Broadcom one, or whether it's fair to say > that the developer community understands Mali better that Broadcom, or > if it's just me drawing some wrong conclusions. > > The driving force at this end is a colleague with sight problems who > can only handle a spreadsheet etc. with a large fount and screen. > Since very often I'm in the position of trying to set up his computer > remotely when he's plugged it into an HDMI TV I've never seen I'm not > exactly enjoying the experience. I don't think I'd exactly enjoy that either. And a spreadsheet w/o a mono-spaced font isn't exactly enjoyable either. We have a truely excellent mono-spaced font, called "hack". Just came out circa a year ago. Truetype I think, it scales up great, I've made yard sale signs with characters 3 inches high with it, and I'm using it right now in the TDE version of kmail-1.9.10. Your colleague might find its very usable for his spreadsheet, or anything else for that matter. I think he'll like it, a lot. re your suggestion to run the edid from tvservice thru edid-ecode, edid-decode doesn't exist on the pi. I'll see if synaptic runs any better on a 24 bit screen and see if I can find something similar. If it will go thru the mail server, its also attached. 32 bytes. Thank you 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>
Attachment:
aocedid
Description: Binary data