The NEW Build Your Own Arcade Controls
Main => Software Forum => Linux => Topic started by: Doozer on March 12, 2019, 08:37:57 am
-
I have released the latest 15 kHz patches with additional features in a dedicated repository.
The purpose of this repository is to keep the 15 kHz patches synchronized with future kernel releases.
Optional patches are also available to make groovymame experience even more realistic and similar to real hardware. If running groovymame is not targetted, they can be omitted.
Link: https://github.com/D0023R/linux_kernel_15khz (https://github.com/D0023R/linux_kernel_15khz)
-
Cool! :cheers:
-
Hey ! Nice decision !
Just out of curiosity : do they work on 4.18+ ?
-
Hey ! Nice decision !
Just out of curiosity : do they work on 4.18+ ?
Thanks.
They should apply fine, if you encounter issue applying them, just reach out to me.
-
Thank you very much for your time and effort to support the latest kernel, this is very much appreciated! As a non-professional linux user I'm having a hard time and looking for some guidance..
I'd love to know if the 15khz-patched-kernel supports super-resolutions as well, because I'm using a computer with an Intel GMA-4 GPU which works great with super-resolutions but I haven't been able to tweak it for native res modelines.
I chose the minimal "ubuntu server 18.04 (amd64, x86_64) (https://help.ubuntu.com/community/Installation/MinimalCD#A64-bit_PC_.28amd64.2C_x86_64.29_.28Recommended.29)" image and installed the 5.2 Kernel from here (https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.2/) without issues following this guide (https://www.itsmearunchandel.co.in/linux/ubuntu/upgrade-kernel-version-in-ubuntu.html).
Then I obtained the 5.2 sources via git from here (http://git.launchpad.net/~ubuntu-kernel-test/ubuntu/+source/linux/+git/mainline-crack) and followed this guide (https://askubuntu.com/questions/724900/how-to-apply-kernel-patches/724909) to apply the patches that were listed along with the 5.2 *.deb packages.
(When I was asked if I wanted to overwrite the config with the one supplied with the packages I chose yes.)
Some of those patches were applied successfully while others asked "where is the file" and I couldn't answer that..
The build/make gave me an error and left me stuck at this point.
There is a more comprehensive guide (https://www.gamoover.net/Forums/index.php?topic=26843.0) in french from MaKoTo but it's pretty outdated I'm afraid.
If anybody would be willing to help, I'd like to return the favor by donating one of these (https://mme4crt.alphanudesign.co.uk/forum/showthread.php?tid=38).
-
Hi,
look at my answer here:
http://forum.arcadecontrols.com/index.php/topic,158903.0.html
It's just a few topics beneath this one.
You should be able to sort it out with a new kernel and Doozer's diff's.
Cheers
-
I'd love to know if the 15khz-patched-kernel supports super-resolutions as well, because I'm using a computer with an Intel GMA-4 GPU which works great with super-resolutions but I haven't been able to tweak it for native res modelines.
If I understand you well, you try to get 15kHz support from an Intel GPU. I assume "GMA-4" makes reference to the 4th Gen chipsets.
The minimum dotclock allowed (without additional patch) is 25MHz for i8xx, 20MHz for i9xx and 25MHz for gen4.
If you give me more details about the chipset I can produce a patch to lower down the value for your chipset. This would in theory enable you to achieve 15kHz output.
-
If I understand you well, you try to get 15kHz support from an Intel GPU. I assume "GMA-4" makes reference to the 4th Gen chipsets.
The minimum dotclock allowed (without additional patch) is 25MHz for i8xx, 20MHz for i9xx and 25MHz for gen4.
If you give me more details about the chipset I can produce a patch to lower down the value for your chipset. This would in theory enable you to achieve 15kHz output.
15KHz actually works with Super-(wide)-resolutions (e.g. 1920x240 or 2560x240 etc.) but I haven't been able to get any native 15KHz-res out of this chipset. As soon as Retroarch's CRTswitchres kicks in everything looks gorgeous and while using Super-resolutions I'm able to display pretty much any system or game the way it's meant to be...
While everything seems fine in retroarch, those Super-resolutions are a real pain when trying to display anything else, commandline, desktop and emulationstation frontend.
As a workaround I've setup a system with attractMode instead of emulationstation as frontend which displays normally under super-wide-15KHz, not stretched and unusuable like everything else.
If there was a way to use *any* 4:3 aspect ratio 15KHz resolution, that would be a dream come true!
Here's some more info on the chipset, also I'd like to offer one of those computers as a donation. They're super small and ideal for consolizing into an emulation-system.
07: PCI 02.0: 0300 VGA compatible controller (VGA)
[Created at pci.366]
Unique ID: _Znp.QUyWiVSQCGD
SysFS ID: /devices/pci0000:00/0000:00:02.0
SysFS BusID: 0000:00:02.0
Hardware Class: graphics card
Model: "Intel 4 Series Chipset Integrated Graphics Controller"
Vendor: pci 0x8086 "Intel Corporation"
Device: pci 0x2e12 "4 Series Chipset Integrated Graphics Controller"
SubVendor: pci 0x103c "Hewlett-Packard Company"
SubDevice: pci 0x3648
Revision: 0x03
Driver: "i915"
Driver Modules: "drm"
Memory Range: 0xf0000000-0xf03fffff (rw,non-prefetchable)
Memory Range: 0xe0000000-0xefffffff (ro,non-prefetchable)
I/O Ports: 0x1230-0x1237 (rw)
IRQ: 31 (33735 events)
I/O Ports: 0x3c0-0x3df (rw)
Module Alias: "pci:v00008086d00002E12sv0000103Csd00003648bc03sc00i00"
Driver Info #0:
Driver Status: i915 is active
Driver Activation Cmd: "modprobe i915"
Config Status: cfg=new, avail=yes, need=no, active=unknown
08: PCI 02.1: 0380 Display controller
[Created at pci.366]
Unique ID: ruGf.xwJ9cLl4Ut2
SysFS ID: /devices/pci0000:00/0000:00:02.1
SysFS BusID: 0000:00:02.1
Hardware Class: graphics card
Model: "Intel 4 Series Chipset Integrated Graphics Controller"
Vendor: pci 0x8086 "Intel Corporation"
Device: pci 0x2e13 "4 Series Chipset Integrated Graphics Controller"
SubVendor: pci 0x103c "Hewlett-Packard Company"
SubDevice: pci 0x3648
Revision: 0x03
Memory Range: 0xf0400000-0xf04fffff (rw,non-prefetchable,disabled)
Module Alias: "pci:v00008086d00002E13sv0000103Csd00003648bc03sc80i00"
Config Status: cfg=new, avail=yes, need=no, active=unknown
Primary display adapter: #7
Hi,look at my answer here:
http://forum.arcadecontrols.com/index.php/topic,158903.0.html
Cheers
That helped a lot and I was able to patch and install the kernel. Thanks!
-
On top of 15kHz patch, just try to apply the following patch to enable low dot clock to i915 chipset. I was not able to find the specs for i915, real test is required. Good luck.
-
Now I'm excited!
Hoping I'll find some time to test this out as soon as possible.
Thank you very much!!! :applaud:
-
On top of 15kHz patch, just try to apply the following patch..
May be a stupid question, but does "on top of" mean before or after the other patches?
-
Normally after the 15kHz patch but due to the fact that it is perform on a separate file both ways will work actually. so, if you do not encounter any error after patching you are fine.
-
I did a full kernel build and I'm afraid either it didn't work or I did something wrong...
Here're my steps:
mkdir src
cd src
wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.2.tar.xz
tar -xf ./linux-5.2.tar.xz
git clone https://github.com/D0023R/linux_kernel_15khz.git
cd linux-5.2/
nano Makefile
# added -15KHz-intel to the version string
sudo su
patch -p1 < ../linux_kernel_15khz/linux-5.2/03_linux_15khz.diff
patch -p1 < ../linux_kernel_15khz/linux-5.2/04_linux_15khz_interlaced_mode_fix.diff
patch -p1 < ../linux_kernel_15khz/linux-5.2/05_linux_15khz_scanoutpos.diff
patch -p1 < ../i915_15khz_test.patch
# had to apply the following patch because of equal names
patch -p1 < ../8-8-drivers-regulator-88pm800-fix-warning-same-module-names.diff
cp /usr/src/linux-headers-5.2.0-050200-generic/.config .
# ran into another error because of a missing dependancy:
apt-get install libelf-dev
make -j$(nproc)
make modules_install
make install
update-grub
Then I bootet into the 5.2xxxx-15KHz-intel kernel and tried some modelines, all with the same message:
xrandr: Configure crtc 0 failed
Here're the modelines I tested:
modeline '240x240' 4,83 240 252 276 310 240 243 246 265 -hsync -vsync
modeline '256x240' 5,30 256 272 296 336 240 244 247 261 -hsync -vsync
modeline '256x256' 5,36 256 268 292 330 256 257 260 273 -hsync -vsync
modeline '256x264' 5,35 256 268 292 330 264 265 268 278 -hsync -vsync
modeline '288x240' 5,84 288 296 328 368 240 243 246 265 -hsync -vsync
modeline '296x240' 5,95 296 304 336 376 240 243 246 264 -hsync -vsync
modeline '304x240' 6,20 304 320 352 396 240 243 246 264 -hsync -vsync
modeline '320x240' 6,45 320 336 368 414 240 242 245 264 -hsync -vsync
modeline '320x256' 6,68 320 340 372 416 256 257 260 268 -hsync -vsync
modeline '336x240' 6,83 336 352 384 433 240 243 246 264 -hsync -vsync
modeline '352x256' 7,28 352 368 400 450 256 257 260 271 -hsync -vsync
modeline '352x264' 7,35 352 365 405 452 264 265 268 284 -hsync -vsync
modeline '352x288' 7,40 352 368 408 464 288 289 292 312 -hsync -vsync
modeline '368x240' 7,47 368 384 424 478 240 243 246 264 -hsync -vsync
modeline '384x288' 7,85 384 400 440 496 288 289 292 309 -hsync -vsync
modeline '392x240' 8,00 392 408 448 504 240 243 246 265 -hsync -vsync
modeline '400x256' 8,08 400 416 456 519 256 268 271 297 -hsync -vsync
modeline '448x240' 9,16 448 464 512 576 240 243 246 265 -hsync -vsync
modeline '512x240' 10,68 512 544 600 672 240 243 246 265 -hsync -vsync
modeline '512x288' 10,68 512 544 600 672 288 289 292 312 -hsync -vsync
modeline '632x264' 13,00 632 664 728 824 264 265 268 278 -hsync -vsync
modeline '640x240' 13,22 640 672 736 832 240 243 246 265 -hsync -vsync
modeline '640x288' 13,10 640 672 736 832 288 289 292 309 -hsync -vsync
And here's the output of lsmod:
Module Size Used by
gpio_ich 16384 0
coretemp 20480 0
i915 1867776 8
kvm 630784 0
irqbypass 16384 1 kvm
snd_hda_codec_realtek 114688 1
hp_wmi 16384 0
sparse_keymap 16384 1 hp_wmi
snd_hda_codec_generic 77824 1 snd_hda_codec_realtek
ledtrig_audio 16384 2 snd_hda_codec_generic,snd_hda_codec_realtek
drm_kms_helper 184320 1 i915
snd_hda_intel 40960 2
wmi_bmof 16384 0
serio_raw 20480 0
input_leds 16384 0
drm 471040 7 drm_kms_helper,i915
joydev 24576 0
snd_hda_codec 126976 3 snd_hda_codec_generic,snd_hda_intel,snd_hda_codec_realtek
i2c_algo_bit 16384 1 i915
fb_sys_fops 16384 1 drm_kms_helper
snd_hda_core 90112 4 snd_hda_codec_generic,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek
syscopyarea 16384 1 drm_kms_helper
snd_hwdep 20480 1 snd_hda_codec
sysfillrect 16384 1 drm_kms_helper
snd_pcm 102400 3 snd_hda_intel,snd_hda_codec,snd_hda_core
sysimgblt 16384 1 drm_kms_helper
snd_timer 36864 1 snd_pcm
snd 81920 11 snd_hda_codec_generic,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek,snd_timer,snd_pcm
soundcore 16384 1 snd
lpc_ich 24576 0
mei_me 40960 0
mei 102400 1 mei_me
tpm_infineon 16384 0
mac_hid 16384 0
sch_fq_codel 20480 2
parport_pc 36864 0
ppdev 24576 0
lp 20480 0
parport 53248 3 parport_pc,lp,ppdev
ip_tables 32768 0
x_tables 40960 1 ip_tables
autofs4 45056 2
hid_generic 16384 0
usbhid 53248 0
hid 131072 2 usbhid,hid_generic
ahci 40960 1
psmouse 151552 0
libahci 32768 1 ahci
e1000e 249856 0
pata_acpi 16384 0
video 49152 1 i915
wmi 28672 2 hp_wmi,wmi_bmof
-
Hi,
Have you checked the log in the syslog or the output of the dmesg command?
-
From specs
The GMCH provides two DPLL clock generator units provide a stable frequency for driving display pipes. It operates by converting an input reference
frequency into an output frequency. The timing generators take their input from internal DPLL devices that are programmable to generate pixel clocks
in the range of 25-400 MHz. Accuracy for VESA timing modes is required to be within ± 0.5%.
Hacking the hardware could allow another (any frequency) clock to be used as per following. But I am not in favor of a hardware hack and it will only work for a predefined dot clock.
The DPLL can take a reference frequency from the external reference input (DREF_CLKINN/P), (DREF_SSCCLKINN/P) the TV clock input (TVCLKIN).
Still...
The frequency of this clock is dependent on the output resolution required.
TV encoder functions are supported together with i915 but via external encoder chip, not a potential path here.
Conclusion:
It does not mean that the 25MHz is a fixed barrier, but only testing and playing with the PLL can reveal us the lower limit with appropriate stability.
-
checked the log in the syslog or dmesg command?
dmesg had nothing unusual in it, besides some ACPI warnings that keep showing under Linux.
Hacking the hardware could allow another (any frequency) clock to be used as per following.
But I am not in favor of a hardware hack and it will only work for a predefined dot clock.
I'd like to mention that I'm much better with a soldering iron than with a Linux command line ;-)
It does not mean that the 25MHz is a fixed barrier, but only testing and playing with the PLL can reveal us the lower limit with appropriate stability.
Of course it would be really awesome to have more modelines available with this chipset, but if it seems like a dead end I'm not stressing to put time and energy into it.
Anyways, I'm open for suggestions and I have some spare time tonight.
Thank you very much for looking into this, still, it's very much appreciated!!
-
I'd like to mention that I'm much better with a soldering iron than with a Linux command line ;-)
Using an external clock to feed the display logic would make the solution too unique and not very practicable due to the need to configure the external clock each time you change the resolution.
-
stupid question : 15khz patches are made to boot in 15khz besides patching a few things here and there. Isn't that a xorg driver problem ? Doozer I remember you saying me something like GM uses DRM, but that's not the case for the OS itself ! (was a few days ago when I asked if we had to patch xorg drivers to allow lower video modes like 160x100)
-
stupid question : 15khz patches are made to boot in 15khz besides patching a few things here and there. Isn't that a xorg driver problem ? Doozer I remember you saying me something like GM uses DRM, but that's not the case for the OS itself ! (was a few days ago when I asked if we had to patch xorg drivers to allow lower video modes like 160x100)
It is correct, the 15kHz patch allows the kernel to boot in 15kHz mode after the kernel is loaded. You can achieve the same result by specifying EDID with 15kHz mode on kernel line or via dongle. In your boot manager, you can append the following to the kernel line "video=VGA-1:e drm_kms_helper.edid_firmware=VGA-1:edid/edid_pal.bin".
X will configure itself to the provided EDID resolution. GM will switch resolution as usual by using the DRM calls.
xf86 library are indeed limited to 320x200 and must be patch to reach lower resolution. Which is not a requirement because they can be managed by GM integer scaling functionality.
-
The 15kHz patches towards freshly released kernel 5.3 are available.
-
Thank you very much for your efforts! This is very much appreciated!
-
Thank you very much :notworthy:. I would like to use these patches and I have a pair of questions:
-Can I use it with an Intel mobile GM965/GL960 graphics controller?
-Does it make possible to select a vertical resolution of 254 lines? (for arcades like MK)
-
Thank you very much :notworthy:. I would like to use these patches and I have a pair of questions:
-Can I use it with an Intel mobile GM965/GL960 graphics controller?
-Does it make possible to select a vertical resolution of 254 lines? (for arcades like MK)
For a Intel GPU, you should use 1280x480 if other resolutions don't work. Need kernel 5.5 at least for that, or you need to backport the patch for previous kernels, or edit the patch that suits your kernel and add the missing resolution yourself. Not that hard to do ;)
As resolution are hard coded in the kernel, there is none with 254 lines. There is a 384x288 at 50Hz in the 5.6 branch though. But you can add the resolution yourself in the kernel.
-
Thank you very much :notworthy:. I would like to use these patches and I have a pair of questions:
-Can I use it with an Intel mobile GM965/GL960 graphics controller?
-Does it make possible to select a vertical resolution of 254 lines? (for arcades like MK)
For a Intel GPU, you should use 1280x480 if other resolutions don't work. Need kernel 5.5 at least for that, or you need to backport the patch for previous kernels, or edit the patch that suits your kernel and add the missing resolution yourself. Not that hard to do ;)
As resolution are hard coded in the kernel, there is none with 254 lines. There is a 384x288 at 50Hz in the 5.6 branch though. But you can add the resolution yourself in the kernel.
Can I select the 384x288@50Hz resolution you mentioned with an Intel GM965/GL960?
-
Sorry for the late reply. Most probably not, intel GPU require a 25MHz pixel clock that is not reached with this resolution. stick to 1280x480i