Saturday, December 21, 2019

XSane preview window bug and failed to start scanner invalid argument

I had a problem the other day with XSane.

It's been working awesome and then one day, the preview window wouldn't come up properly, basically a blank window.

And then I couldn't scan anything, getting an error dialog that said "Failed to start scanner: Invalid argument".





This was driving me crazy, I power cycled the hp printer/all in one 5740 but it wouldn't work at all.


So let's see if we can scan with scanimage.

scanimage -d hpaio:/net/Officejet_5740_series?ip=192.168.1.10 --format=tiff > mytest2.tiff


That worked! So why was I getting the invalid argument error? Looking carefully I saw that the area to scan was set to basically zero. The rectangle specified was basically of zero area. If you look at the top left it's set to 8.5 and 11.69 and the bottom right is 8.5 and 11.69. I must have clicked somewhere in the "blank" preview window that set these coordinates.

It'd be nice if it said "Scan Area Coordinates invalid" instead of just "invalid argument".


I see that other people have been having the same bug with the preview window:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867667

What's interesting is that opening the preview window with CTRL+1 seems to have fixed it. Opening it with the menu Window/Show Preview was giving me the blank screen.


Anyway, I can happily scan again!


Just for fun, let's see how small a region we can actually scan without getting the "Failed to start scanner: Invalid argument" error.


The smallest I can scan is 1x1x24 (3.0B) for 3 bytes!

Wednesday, November 20, 2019

Weirdness with VGA to HDMI adapter and i915

So I've got an older TV that I wanted to use with a laptop and do triple monitors. The laptop has got its own 1600x900 built-in screen, and on the hdmi port I've connected a DVI 1920x1200 monitor and then there's a Toshiba 40FT1U on the VGA port.

The only problem is that the Toshiba 40FT1U doesn't like anything higher than 1280x1024 or 1366x768 on the VGA port. Checking with the manual, sure enough that's the maximum on VGA-in but HDMI-in will give you the full 1080p resolution.



I got on ebay and found a cheap VGA to HDMI adapter. The only problem is that I couldn't get Ubuntu 19.04 to output a video signal that xrandr would like.

The VGA to HDMI adapter had no EDID information, and get-edid wouldn't return anything.

Firing up cvt 1920 1080 60, I would make an xrandr newmode of 1920x1080.


$ cvt 1920 1080 60
# 1920x1080 59.96 Hz (CVT 2.07M9) hsync: 67.16 kHz; pclk: 173.00 MHz
Modeline "1920x1080_60.00"  173.00  1920 2048 2248 2576  1080 1083 1088 1120 -hsync +vsync
$ xrandr --newmode "1920x1080_60.00"  173.00  1920 2048 2248 2576  1080 1083 1088 1120 -hsync +vsync
$ xrandr --addmode VGA-1 "1920x1080_60.00"
$ xrandr --output VGA-1 --mode "1920x1080_60.00"
xrandr: Configure crtc 1 failed



Sadly, that didn't work at all giving a "Configure crtc 1 failed" message.

Looking at my xorg log it says just Invalid argument:


$ less ~/.local/share/xorg/Xorg.0.log 
[   405.766] (II) modeset(0): Allocate new frame buffer 5440x1200 stride
[  1196.778] (EE) modeset(0): failed to set mode: Invalid argument




What's strange is that I can do a resolution of 1912x1080:


$ cvt 1912 1080 60
# 1912x1080 59.91 Hz (CVT) hsync: 67.10 kHz; pclk: 171.25 MHz
Modeline "1912x1080_60.00"  171.25  1912 2032 2232 2552  1080 1083 1093 1120 -hsync +vsync
$ xrandr --newmode "1912x1080_60.00"  171.25  1912 2032 2232 2552  1080 1083 1093 1120 -hsync +vsync
$ xrandr --addmode VGA-1 "1912x1080_60.00"
$ xrandr --output VGA-1 --mode "1912x1080_60.00"



So 1912x1080x60 works no problem, which is really strange. The only problem is that my VGA to HDMI adapter scrunches the screen horizontally, which is usable but it offends me terribly. Not having 1 to 1 pixels grated on me.

I've got another television a 50 inch emerson with a VGA input, and weirdly, plugging the VGA into it allows me to set a 1920x1080x60 resolution. Oddly, it has no EDID information either but the 1920x1080 resolution will work.


So I thought, let's see if we can get a working edid from another monitor and use that.

On another system with a sceptre monitor that was 1920x1080 I ran "sudo get-edid > sceptre_edid.bin".

Then I made a /usr/firmware/edid directory with "sudo mkdir /usr/firmware/edid" then "sudo cp sceptre_edid.bin /usr/firmware/edid/"/

Locating the file /etc/default/grub and running "sudo nano /etc/default/grub"


and making these changes:
GRUB_TIMEOUT=10
GRUB_TIMEOUT_STYLE=menu

GRUB_CMDLINE_LINUX=" drm.edid_firmware=VGA-1:edid/sceptre_edid.bin"



then "sudo update-grub"

and now it comes up just fine with 1920x1080 on the VGA-1 port.

So what is actually not working? Let's take a closer look at the EDID file with parse-edid.


$ cat sceptre_edid.bin | parse-edid
Checksum Correct

Section "Monitor"
 Identifier "E275W-1920"
 ModelName "E275W-1920"
 VendorName "SPT"
 # Monitor Manufactured week 6 of 2015
 # EDID version 1.3
 # Analog Display
 Option "SyncOnGreen" "true"
 DisplaySize 600 340
 Gamma 2.20
 Option "DPMS" "true"
 Horizsync 30-95
 VertRefresh 56-75
 # Maximum pixel clock is 180MHz
 #Not giving standard mode: 1280x800, 60Hz
 #Not giving standard mode: 1280x960, 60Hz
 #Not giving standard mode: 1280x1024, 60Hz
 #Not giving standard mode: 1440x900, 60Hz
 #Not giving standard mode: 1600x1200, 60Hz
 #Not giving standard mode: 1680x1050, 60Hz
 Modeline  "Mode 0" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync 
 Modeline  "Mode 1" 118.97 1600 1712 1864 2112 900 901 904 932 -hsync +vsync 
EndSection


That modeline of "Mode 0" is 1920x1080 but the numbers are different from what cvt gives:


Comparing the two modelines, the numbers vary slightly and the hsync is opposite polarity.

Modeline "1920x1080_60.00"  173.00   1920 2048 2248 2576   1080 1083 1088 1120 -hsync +vsync
Modeline "Mode 0"           148.50   1920 2008 2052 2200   1080 1084 1089 1125 +hsync +vsync


Let's compare it to a reduced blanking modeline from cvt, now you'll notice that the vsync is opposite.

$ cvt 1920 1080 60 -r
# 1920x1080 59.93 Hz (CVT 2.07M9-R) hsync: 66.59 kHz; pclk: 138.50 MHz
Modeline "1920x1080R" 138.50 1920 1968 2000 2080 1080 1083 1088 1111 +hsync -vsync
Modeline "Mode 0" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync



So I tried rebooting ubuntu *without* the drm.edid_firmware=VGA-1:edid/sceptre_edid.bin and it went right back to hating my cvt 1920 1080 60 modeline.

But let's try the modeline from the sceptre edid "Mode 0".

$ xrandr --newmode "Mode 0" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
$ xrandr --addmode VGA-1 "Mode 0"
$ xrandr --output VGA-1 --mode "Mode 0"

Hah! It likes that modeline!

It also seems to like the reduced blanking version.

$ cvt -r 1920 1080 60
# 1920x1080 59.93 Hz (CVT 2.07M9-R) hsync: 66.59 kHz; pclk: 138.50 MHz
Modeline "1920x1080R" 138.50 1920 1968 2000 2080 1080 1083 1088 1111 +hsync -vsync
$ xrandr --newmode "1920x1080R" 138.50 1920 1968 2000 2080 1080 1083 1088 1111 +hsync -vsync
$ xrandr --addmode VGA-1 "1920x1080R"
$ xrandr --output VGA-1 --mode "1920x1080R"


I also tried gtf and that didn't work. xrandr: Configure crtc 1 failed

Strangely, using drm.edid_firmware=VGA-1:edid/1920x1080.bin would work on the VGA to HDMI but for some reason I'd lose the other monitor.
(This would use a "built-in" 1920x1080 edid file)


The actual 1920x1080 timings can vary, here's a couple of monitors that have 1125 as the last number of the modeline.


From https://cdn.kramerav.com/web/downloads/white-papers/analog_edid_whitepaper_6.pdf:

"Knowing that the standardization problem exists mostly in widescreen resolutions, let us look at an example using 1920x1080.
These mode lines came from the EDIDs of the computer graphics video inputs of different 1080p monitors:"


Monitor 1 – LG LCD 
• Detailed timing #1....... 1920x1080p at 60Hz (16:9) 
• Mode line............... “1920x1080” 148.500 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync 
Monitor 2 – Westinghouse LCD 
• Native/preferred timing.... 1920x1080p at 60Hz (16:9) 
• Mode line............... “1920x1080” 138.500 1920 1968 2000 2080 1080 1082 1087 1111 +hsync -vsync 
Monitor 3 – Samsung LCD 
• Native/preferred timing.. 1920x1080p at 60Hz (16:9) 
• Mode line............... “1920x1080” 138.500 1920 1968 2000 2080 1080 1083 1088 1111 +hsync -vsync 
Monitor 4 – Panasonic Plasma 
• Detailed timing #1....... 1920x1080p at 60Hz 
• Mode line............... “1920x1080” 148.500 1920 2008 2052 2200 1080 1084 1089 1125 -hsync –vsync 
Monitor 5 – Vizio LCD 
• Native/preferred timing.. 1920x1080p at 60Hz 
• Mode line............... “1920x1080” 136.500 1920 1952 1984 2048 1080 1081 1084 1111 +hsync +vsync 

"You can clearly see that while all these monitors claim to be 1920x1080 monitors, they each support a different version of 1920x1080. It is also clear that describing active pixels alone is not specific enough to define a resolution. Display manufacturers have taken to producing non-standard displays, because the specific timings are completely described in the EDID of the monitors they build. When a computer is connected directly to any of these monitors, the mode line is read by the PC and automatically the PC modifies its output to comply properly with that display."



Now with the edid file I can get my VGA to HDMI adapter to work with full 1920x1080 resolution automatically or using the "Mode 0" modeline from the edid file I can get xrandr to work. The VGA to HDMI output really looks good on the tv.

Friday, July 19, 2019

Non blocking reads in lua

So I wanted to try reading some midi data from my keyboard with lua and ubuntu. I installed lua 5.3 and lua posix with "sudo apt install lua5.3 lua-posix"


Then I plugged in my M-Audio Keyrig 49 to the usb and tested it with "aseqdump -l" to list the midi devices then "aseqdump -p 24:0" since it came up on port 24:0.

Ok, so now for the lua (something quick and hacky to test it):

The keyrig will generate 0x90 key on and always 3 bytes for each midi message (0x90 status, then pitch, the velocity) so that makes it really easy.


and some sample output:


................................................

90
3b
39
KEY=59 VELOCITY=57
.......................*.........................
9
90
3c
36
KEY=60 VELOCITY=54
.......................**........................
6
90
3e
23
KEY=62 VELOCITY=35
.......................**.*......................

Saturday, May 4, 2019

MTU 80 Column 3d hat

I remember this program that I typed in from a magazine years ago that would draw a neat 3d function. So let's see if we can find it:


https://j-b.livejournal.com/268176.html
Atari 8-bit "Archimedes Spiral" demo - FOUND!


I searched google for:
mtu commodore pet graphics "high-resolution"
which led me to an ebay ad and if you look closely it says "May 1981" so let's see what we can find for ads for MTU in may 1981.





Micro, the 6502 magazine, may 1981 page
http://archive.6502.org/publications/micro/micro_36_may_1981.pdf

I found the original source for the ebay ad picture:

https://archive.org/details/creativecomputing-1981-05/page/n67





And another page that mentions the MTU ad and rewriting it in 68000

http://www.easy68k.com/paulrsm/dg/dg07.htm


It was originally for the PET with a MTU graphics board, but it wasn't hard to convert to Apple II Applesoft Basic, but I kept getting illegal quantity errors on the hplots being outside of the range 0-279 for x and 0-191 for y so there's code to keep them within range.

You can paste the program into mame's lua console and then unthrottle with F10 and set the frameskip to skip 10/10 it to run it really fast. If you shrink the mame window it will go even faster. I think I can get it to 1200% on my system so it only takes about 8 minutes.



emu.keypost([[
   NEW
 10 HGR2 : HCOLOR=3
 20 P=160 : Q=100
 30 XP=120:XR=1.5*3.1415927
 40 YP=56:YR=1:ZP=64
 50 XF=XR/XP:YF=YP/YR:ZF=XR/ZP
 60 FOR ZI=-Q TO Q-1
 70 IF ZI<-ZP OR ZI>ZP GOTO 150
 80 ZT=ZI*XP/ZP:ZZ=ZI
 90 XL=INT(.5+SQR(XP*XP-ZT*ZT))
 100 FOR XI=-XL TO XL
 110 XT=SQR(XI*XI+ZT*ZT)*XF:XX=XI
 120 YY=(SIN(XT)+.4*SIN(3*XT))*YF
 130 GOSUB 170
 140 NEXT XI
 150 NEXT ZI
 160 STOP
 170 X1=XX+ZZ+P
 180 Y1=YY-ZZ+Q
 181 IF Y1<1 THEN Y1=1  : REM MUST BE 1 OR ERROR IN 210
 182 IF Y1>191 THEN Y1=191
 183 IF X1<0 THEN X1=0
 184 IF X1>279 THEN X1=279
 190 HCOLOR=3:HPLOT X1,191-Y1
 210 HCOLOR=0:HPLOT X1,191-(Y1-1) TO X1,191-0
 220 RETURN
 RUN
]])


I also like this applesoft program to plot the gaussian distribution in 3d on codegolf:

https://codegolf.stackexchange.com/questions/123039/plot-the-gaussian-distribution-in-3d/123079


Wednesday, March 27, 2019

Some Ubuntu resume weirdness, lose mouse, sound



For some reason, I keep losing my mouse on resume. I can unplug it from the top of my keyboard and then plug it in and it will come back. I've also noticed that it will come back properly if I keep moving the mouse during the resume process, until the screen comes back and I can see the mouse moving. What's weird when it happens is that the scroll wheel works, but I can't move the mouse at all until doing an unplug/replug cycle.


Also sometimes I will lose my sound which is pretty irritating.



https://superuser.com/questions/845645/pulseaudio-how-to-rescan-audio-devices



https://askubuntu.com/questions/517578/no-sound-after-suspend-standby


This command will re-detect the sound devices:


pacmd unload-module module-udev-detect && pacmd load-module module-udev-detect



Also you can ask alsa to force reload itself, just doing sudo alsa force-reload didn't bring my sound back, I also had to do the pacmd unload-module module-udev-detect && pacmd load-module module-udev-detect.



sudo alsa force-reload
cat /proc/asound/cards
pacmd list-sinks
pacmd unload-module module-udev-detect && pacmd load-module module-udev-detect
pacmd list-sinks

Tuesday, January 29, 2019

Stellar 7 text font at 0x7900


I found the text font at 0x7900. It goes from character 32 (space) to 127. 126 and 127 are tiny flag symbols.

and we can write some lua to write some text to the screen:




Monday, January 28, 2019

More COS routine multiply analysis.

Binary math really melts my brain. I'm not really designed to function in binary so I've been trying to figure out how the multiply routine ends up with a costable value * multiplicand *2.


I think it's useful to build a model to see exactly what's happening with the bits.




And if I run this in mame's lua console I can better see where all those bits are going:

7 bits of multiplier
mem00=7f
mem01=ff
LDX $01=ff
DEX
STX $01=fe
LDA $00=7f
LSR A=3f
STA $02=3f
LDA #$00 a=00
BEFORE ADC $01=fe  a=00 00000000
ADD    ADC (c=1+$01)=ff 11111111
AFTER  ADC $01=fe  a=ff 11111111 c=0
BEFORE ROL: 0_11111111_00111111
ROL8 BEFORE= ff  carry= 0  11111111
ROL8 AFTER = 7f  carry= 1  01111111
ROL8 BEFORE= 3f  carry= 1  00111111
ROL8 AFTER = 9f  carry= 1  10011111
AFTER ROL:  1_01111111_10011111
1 7f 01111111 9f 10011111
BEFORE ADC $01=fe  a=7f 01111111
ADD    ADC (c=1+$01)=ff 11111111
AFTER  ADC $01=fe  a=7e 01111110 c=1
BEFORE ROL: 1_01111110_10011111
ROL8 BEFORE= 7e  carry= 1  01111110
ROL8 AFTER = bf  carry= 0  10111111
ROL8 BEFORE= 9f  carry= 0  10011111
ROL8 AFTER = 4f  carry= 1  01001111
AFTER ROL:  1_10111111_01001111
1 bf 10111111 4f 01001111
BEFORE ADC $01=fe  a=bf 10111111
ADD    ADC (c=1+$01)=ff 11111111
AFTER  ADC $01=fe  a=be 10111110 c=1
BEFORE ROL: 1_10111110_01001111
ROL8 BEFORE= be  carry= 1  10111110
ROL8 AFTER = df  carry= 0  11011111
ROL8 BEFORE= 4f  carry= 0  01001111
ROL8 AFTER = 27  carry= 1  00100111
AFTER ROL:  1_11011111_00100111
1 df 11011111 27 00100111
BEFORE ADC $01=fe  a=df 11011111
ADD    ADC (c=1+$01)=ff 11111111
AFTER  ADC $01=fe  a=de 11011110 c=1
BEFORE ROL: 1_11011110_00100111
ROL8 BEFORE= de  carry= 1  11011110
ROL8 AFTER = ef  carry= 0  11101111
ROL8 BEFORE= 27  carry= 0  00100111
ROL8 AFTER = 13  carry= 1  00010011
AFTER ROL:  1_11101111_00010011
1 ef 11101111 13 00010011
BEFORE ADC $01=fe  a=ef 11101111
ADD    ADC (c=1+$01)=ff 11111111
AFTER  ADC $01=fe  a=ee 11101110 c=1
BEFORE ROL: 1_11101110_00010011
ROL8 BEFORE= ee  carry= 1  11101110
ROL8 AFTER = f7  carry= 0  11110111
ROL8 BEFORE= 13  carry= 0  00010011
ROL8 AFTER = 09  carry= 1  00001001
AFTER ROL:  1_11110111_00001001
1 f7 11110111 09 00001001
BEFORE ADC $01=fe  a=f7 11110111
ADD    ADC (c=1+$01)=ff 11111111
AFTER  ADC $01=fe  a=f6 11110110 c=1
BEFORE ROL: 1_11110110_00001001
ROL8 BEFORE= f6  carry= 1  11110110
ROL8 AFTER = fb  carry= 0  11111011
ROL8 BEFORE= 09  carry= 0  00001001
ROL8 AFTER = 04  carry= 1  00000100
AFTER ROL:  1_11111011_00000100
1 fb 11111011 04 00000100
BEFORE ADC $01=fe  a=fb 11111011
ADD    ADC (c=1+$01)=ff 11111111
AFTER  ADC $01=fe  a=fa 11111010 c=1
BEFORE ROL: 1_11111010_00000100
ROL8 BEFORE= fa  carry= 1  11111010
ROL8 AFTER = fd  carry= 0  11111101
ROL8 BEFORE= 04  carry= 0  00000100
ROL8 AFTER = 02  carry= 0  00000010
AFTER ROL:  0_11111101_00000010
0 fd 11111101 02 00000010
[MAME]> 
[MAME]> print(hex(0xff * 0x7f * 2))
fd02
[MAME]>