Main Restorations Software Audio/Jukebox/MP3 Everything Else Buy/Sell/Trade
Project Announcements Monitor/Video GroovyMAME Merit/JVL Touchscreen Meet Up Retail Vendors
Driving & Racing Woodworking Software Support Forums Consoles Project Arcade Reviews
Automated Projects Artwork Frontend Support Forums Pinball Forum Discussion Old Boards
Raspberry Pi & Dev Board controls.dat Linux Miscellaneous Arcade Wiki Discussion Old Archives
Lightguns --- Bug Reports --- Site News

Unread posts | New Replies | Recent posts | Rules | Chatroom | Wiki | File Repository | RSS | Submit news

  

Author Topic: Linux 15kHz patches  (Read 720 times)

0 Members and 1 Guest are viewing this topic.

Doozer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 400
  • Last login:Yesterday at 02:34:23 pm
  • Z80 ERROR
Linux 15kHz patches
« on: March 12, 2019, 08:37:38 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

donluca

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 144
  • Last login:Today at 07:11:19 am
  • I want to build my own arcade controls!
Re: Linux 15kHz patches
« Reply #1 on: March 12, 2019, 05:56:52 pm »
Wow, thanks for this! I'll definitely take a peek.

Also, this means we can now make our own GroovyMAME distro, right?

keilmillerjr

  • Trade Count: (+5)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1629
  • Last login:Today at 08:26:35 pm
  • Web Developer.
Re: Linux 15kHz patches
« Reply #2 on: March 12, 2019, 11:39:24 pm »
Woohoo for linux support! What would be different to the end user in lamens terms with the optional scanline reporting position patch?

Doozer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 400
  • Last login:Yesterday at 02:34:23 pm
  • Z80 ERROR
Re: Linux 15kHz patches
« Reply #3 on: March 13, 2019, 04:12:41 am »
Woohoo for linux support! What would be different to the end user in lamens terms with the optional scanline reporting position patch?

In the current GM release having a kernel with the scanline patch will change nothing. The system will behave exactly the same way.

Somewhere in the future, GM might be enhanced with a set of new functions that would enable better frame_delay mechanism. Still, the patch will be optional and the system will detect if the kernel has it applied or not to select the appropriate method.


Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 40
  • Last login:Today at 06:41:40 pm
  • I want to build my own arcade controls!
Re: Linux 15kHz patches
« Reply #4 on: March 13, 2019, 05:42:28 am »
Looks like making a linux-15khz arch kernel package could be useful for GroovyArcade (easier build, easier updates) ! I'll have a look at it in the coming days

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6552
  • Last login:Today at 02:43:53 pm
Re: Linux 15kHz patches
« Reply #5 on: March 14, 2019, 11:38:04 am »
In the future, I'd like that custom-kHz kernel mode setting is achieved through EDID emulation rather than kernel hardcoded modelines. This has been succesfully tested in the past but has never been implemented in a customizable way.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 40
  • Last login:Today at 06:41:40 pm
  • I want to build my own arcade controls!
Re: Linux 15kHz patches
« Reply #6 on: March 14, 2019, 05:01:21 pm »
In the future, I'd like that custom-kHz kernel mode setting is achieved through EDID emulation rather than kernel hardcoded modelines. This has been succesfully tested in the past but has never been implemented in a customizable way.

Do you mean something like https://github.com/Ansa89/linux-15khz-patch/tree/master/edid ?

Doozer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 400
  • Last login:Yesterday at 02:34:23 pm
  • Z80 ERROR
Re: Linux 15kHz patches
« Reply #7 on: March 15, 2019, 08:08:57 am »
In the future, I'd like that custom-kHz kernel mode setting is achieved through EDID emulation rather than kernel hardcoded modelines. This has been succesfully tested in the past but has never been implemented in a customizable way.

I must admit that I never tested custom EDID solution via kernel commandline. I was convinced that this would work with recent monitor but not usable on CRT. If it was successfully tested, does it means that the EDID can override the ppl dot clock limitation in the driver? I always used it in combination with the 15 kHz patch.
« Last Edit: March 16, 2019, 02:29:45 am by Doozer »

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 40
  • Last login:Today at 06:41:40 pm
  • I want to build my own arcade controls!
Re: Linux 15kHz patches
« Reply #8 on: March 15, 2019, 09:25:16 am »
EDID is supposed to provide the different modes that are supported by a screen. If that means writing modes for every possible resolutions, or just a few custom super resolutions, we'd need to check that the EDID standard allows more than 1 custom mode, which I doubt.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6552
  • Last login:Today at 02:43:53 pm
Re: Linux 15kHz patches
« Reply #9 on: March 15, 2019, 02:02:03 pm »
EDID is supposed to provide the different modes that are supported by a screen. If that means writing modes for every possible resolutions, or just a few custom super resolutions, we'd need to check that the EDID standard allows more than 1 custom mode, which I doubt.

No, I don't mean that. Using EDID overrides as the custom video source for emulation is a big step backwards.

I mean this.

This is meant for the boot process only. Once you launch X, it's X which handles custom video through X modelines, in a totally flexible way.

What this allows is to boot at 15 kHz with a stock kernel.

(Or any random frequency, not everything is 15 kHz).
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Doozer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 400
  • Last login:Yesterday at 02:34:23 pm
  • Z80 ERROR
Re: Linux 15kHz patches
« Reply #10 on: March 16, 2019, 02:07:03 am »

I will do some fresher tests to confirm.

Doozer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 400
  • Last login:Yesterday at 02:34:23 pm
  • Z80 ERROR
Re: Linux 15kHz patches
« Reply #11 on: March 16, 2019, 02:27:36 am »

I did run some tests and I can confirm that the EDID parameter on the kernel command line is indeed doing the job. It means that 15kHz is perfectly doable without the 15 kHz patch.

Only issue is with the interlaced resolution. In such a case you still need to apply the fix to get the correct emulation speed. This can be resolved with next GM development and timing the vblank.

Forcing another resolution via xorg.conf is no more possible. Using xrandr and libdrm is working as expected. Groovymame video output is not impacted.

Code: [Select]
[   664.729] (II) RADEON(0): EDID vendor "SWR", prod id 0
[   664.729] (II) RADEON(0): Using hsync ranges from config file
[   664.729] (II) RADEON(0): Using vrefresh ranges from config file
[   664.729] (II) RADEON(0): Printing DDC gathered Modelines:
[   664.729] (II) RADEON(0): Modeline "768x576i"x0.0   14.87  768 792 864 952  576 582 587 625 interlace -hsync -vsync (15.6 kHz eP)
« Last Edit: March 16, 2019, 03:29:56 am by Doozer »

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 40
  • Last login:Today at 06:41:40 pm
  • I want to build my own arcade controls!
Re: Linux 15kHz patches
« Reply #12 on: May 07, 2019, 04:15:15 am »
Thank you for being so reactive and keeping your patches always up to date ! that really saved me some time with the 5.1 bump ;)

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 40
  • Last login:Today at 06:41:40 pm
  • I want to build my own arcade controls!
Re: Linux 15kHz patches
« Reply #13 on: May 15, 2019, 02:44:35 pm »

I did run some tests and I can confirm that the EDID parameter on the kernel command line is indeed doing the job. It means that 15kHz is perfectly doable without the 15 kHz patch.

Only issue is with the interlaced resolution. In such a case you still need to apply the fix to get the correct emulation speed. This can be resolved with next GM development and timing the vblank.

Forcing another resolution via xorg.conf is no more possible. Using xrandr and libdrm is working as expected. Groovymame video output is not impacted.

Code: [Select]
[   664.729] (II) RADEON(0): EDID vendor "SWR", prod id 0
[   664.729] (II) RADEON(0): Using hsync ranges from config file
[   664.729] (II) RADEON(0): Using vrefresh ranges from config file
[   664.729] (II) RADEON(0): Printing DDC gathered Modelines:
[   664.729] (II) RADEON(0): Modeline "768x576i"x0.0   14.87  768 792 864 952  576 582 587 625 interlace -hsync -vsync (15.6 kHz eP)

Which kernel version were you using ? I've tried with arch 5.1.2 in virtual box, i get no EDID message in kernel log, and xorg reports the EDID from virtual box ... I've seen a bug at freedesktop mentionning it was broken since 4.15 ...

Doozer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 400
  • Last login:Yesterday at 02:34:23 pm
  • Z80 ERROR
Re: Linux 15kHz patches
« Reply #14 on: May 18, 2019, 10:23:10 am »

I did run some tests and I can confirm that the EDID parameter on the kernel command line is indeed doing the job. It means that 15kHz is perfectly doable without the 15 kHz patch.

Only issue is with the interlaced resolution. In such a case you still need to apply the fix to get the correct emulation speed. This can be resolved with next GM development and timing the vblank.

Forcing another resolution via xorg.conf is no more possible. Using xrandr and libdrm is working as expected. Groovymame video output is not impacted.

Code: [Select]
[   664.729] (II) RADEON(0): EDID vendor "SWR", prod id 0
[   664.729] (II) RADEON(0): Using hsync ranges from config file
[   664.729] (II) RADEON(0): Using vrefresh ranges from config file
[   664.729] (II) RADEON(0): Printing DDC gathered Modelines:
[   664.729] (II) RADEON(0): Modeline "768x576i"x0.0   14.87  768 792 864 952  576 582 587 625 interlace -hsync -vsync (15.6 kHz eP)

Which kernel version were you using ? I've tried with arch 5.1.2 in virtual box, i get no EDID message in kernel log, and xorg reports the EDID from virtual box ... I've seen a bug at freedesktop mentionning it was broken since 4.15 ...
Hi,

Not sure virtual box is emulating edid feature on the virtual video output. The standard kernel driver or specific virtio must be checked to see if edid helper is provided.

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 40
  • Last login:Today at 06:41:40 pm
  • I want to build my own arcade controls!
Re: Linux 15kHz patches
« Reply #15 on: May 18, 2019, 12:31:58 pm »
Hi,

Not sure virtual box is emulating edid feature on the virtual video output. The standard kernel driver or specific virtio must be checked to see if edid helper is provided.
Oh well, I'm good to test this straight on a computer rather than a VM .. too bad