schmerlo
Posts: 10
Joined: Wed Nov 07, 2018 10:35 am

Re: Multiple Frame buffer beta testers wanted

Thu Nov 08, 2018 5:11 pm

jamesh wrote:
Thu Nov 08, 2018 2:42 pm
schmerlo wrote:
Thu Nov 08, 2018 1:44 pm
aBUGSworstnightmare wrote:
Thu Nov 08, 2018 11:30 am
Can you please inform which displays you have connected to the zero and how (as I have no idea what DLP2000) is ...

Your ' framebuffer_priority" should be HDMI ' framebuffer_priority=2"
Start with 'max_framebuffers=1' to see if your setup/config/installation is working at all ...
I already checked it with max_framebuffers=1. framebuffer_priority=2 didnt change anything. Still hangs quite early in the boot sequence (not even the rainbow image).

The DLP2000 or DLPDLCR2000EVM is a Ti Evaluation Module for their DMD Projector. Its hooked up via DPI18 Interface.
Does that device work without the multifb support? I did test a DPI display attached via a Adafruit Kippah, which did work.
The device works fine using the unmodified start_x in either mirror console mode (display_default_lcd=1) or using the omxplayer to access the Projector directly. Here is my config.txt for reference:

Code: Select all

# Added to support DLP2000, I2C Pins moved because we need the pins for DPI
dtoverlay=i2c-gpio,i2c_gpio_sda=23,i2c_gpio_scl=24,i2c_gpio_delay_us=2

# Enable DPI Interface
dtoverlay=dpi18
overscan_left=0
overscan_right=0
overscan_top=0
overscan_bottom=0
framebuffer_width=854
framebuffer_height=480
enable_dpi_lcd=1
display_default_lcd=0
dpi_group=2
dpi_mode=87

dpi_output_format=458773
hdmi_timings=854 0 14 4 12 480 0 2 3 9 0 0 0 60 0 32000000 3

# We need I2c to configure the DLP2000
dtparam=i2c_arm=on
start_x=1

max_framebuffers=1
# x = 0 LCD, 2 for HDMI
# MAIN_LCD 0
# AUX_LCD 1
# HDMI 2
# SDTV 3
framebuffer_priority=2

luciodeep
Posts: 9
Joined: Tue Oct 23, 2018 9:56 pm

Re: Multiple Frame buffer beta testers wanted

Thu Nov 08, 2018 6:30 pm

schmerlo wrote:
Thu Nov 08, 2018 5:11 pm
jamesh wrote:
Thu Nov 08, 2018 2:42 pm
schmerlo wrote:
Thu Nov 08, 2018 1:44 pm


I already checked it with max_framebuffers=1. framebuffer_priority=2 didnt change anything. Still hangs quite early in the boot sequence (not even the rainbow image).

The DLP2000 or DLPDLCR2000EVM is a Ti Evaluation Module for their DMD Projector. Its hooked up via DPI18 Interface.
Does that device work without the multifb support? I did test a DPI display attached via a Adafruit Kippah, which did work.
The device works fine using the unmodified start_x in either mirror console mode (display_default_lcd=1) or using the omxplayer to access the Projector directly. Here is my config.txt for reference:

Code: Select all

# Added to support DLP2000, I2C Pins moved because we need the pins for DPI
dtoverlay=i2c-gpio,i2c_gpio_sda=23,i2c_gpio_scl=24,i2c_gpio_delay_us=2

# Enable DPI Interface
dtoverlay=dpi18
overscan_left=0
overscan_right=0
overscan_top=0
overscan_bottom=0
framebuffer_width=854
framebuffer_height=480
enable_dpi_lcd=1
display_default_lcd=0
dpi_group=2
dpi_mode=87

dpi_output_format=458773
hdmi_timings=854 0 14 4 12 480 0 2 3 9 0 0 0 60 0 32000000 3

# We need I2c to configure the DLP2000
dtparam=i2c_arm=on
start_x=1

max_framebuffers=1
# x = 0 LCD, 2 for HDMI
# MAIN_LCD 0
# AUX_LCD 1
# HDMI 2
# SDTV 3
framebuffer_priority=2
Maybe add disable_overscan=1 may help

aBUGSworstnightmare
Posts: 1349
Joined: Tue Jun 30, 2015 1:35 pm

Re: Multiple Frame buffer beta testers wanted

Thu Nov 08, 2018 6:48 pm

schmerlo wrote:
Thu Nov 08, 2018 5:11 pm
jamesh wrote:
Thu Nov 08, 2018 2:42 pm
schmerlo wrote:
Thu Nov 08, 2018 1:44 pm


I already checked it with max_framebuffers=1. framebuffer_priority=2 didnt change anything. Still hangs quite early in the boot sequence (not even the rainbow image).

The DLP2000 or DLPDLCR2000EVM is a Ti Evaluation Module for their DMD Projector. Its hooked up via DPI18 Interface.
Does that device work without the multifb support? I did test a DPI display attached via a Adafruit Kippah, which did work.
The device works fine using the unmodified start_x in either mirror console mode (display_default_lcd=1) or using the omxplayer to access the Projector directly. Here is my config.txt for reference:

Code: Select all

# Added to support DLP2000, I2C Pins moved because we need the pins for DPI
dtoverlay=i2c-gpio,i2c_gpio_sda=23,i2c_gpio_scl=24,i2c_gpio_delay_us=2

# Enable DPI Interface
dtoverlay=dpi18
overscan_left=0
overscan_right=0
overscan_top=0
overscan_bottom=0
framebuffer_width=854
framebuffer_height=480
enable_dpi_lcd=1
display_default_lcd=0
dpi_group=2
dpi_mode=87

dpi_output_format=458773
hdmi_timings=854 0 14 4 12 480 0 2 3 9 0 0 0 60 0 32000000 3

# We need I2c to configure the DLP2000
dtparam=i2c_arm=on
start_x=1

max_framebuffers=1
# x = 0 LCD, 2 for HDMI
# MAIN_LCD 0
# AUX_LCD 1
# HDMI 2
# SDTV 3
framebuffer_priority=2
delete (commend-out) commands mentioned below:

Code: Select all

framebuffer_width=854
framebuffer_height=480
display_default_lcd=0 

Code: Select all

hdmi_timings=854 0 14 4 12 480 0 2 3 9 0 0 0 60 0 32000000 3 
this is no longer valid for DPI as we now have a dpi_timings command. As it now screws up your HDMI timing (thanks to jamesh we have consistent naming now ) change to

Code: Select all

dpi_timings=854 0 14 4 12 480 0 2 3 9 0 0 0 60 0 32000000 3  
framebbuffer size will be used from the dpi_timings line, default display is selected via frambuffer_priority command.

Overscan schould be removed; if you have black borders on DPI your timing is trash.

Report back if these changes do the trick.

Just for sanity check: you have changed 99-fbturbo.conf entry and you're using the correct modukes (rpi-update xx as described starting from here viewtopic.php?f=63&t=216399&start=225#p1381675)?

aBUGSworstnightmare
Posts: 1349
Joined: Tue Jun 30, 2015 1:35 pm

Testing the multi framebuffer on LVDS4CM3L

Fri Nov 09, 2018 4:18 am

Hi,

prepared a short video, showing a short test of the multi-framebuffer beta.

https://youtu.be/HFYg63suLoM
Last edited by aBUGSworstnightmare on Sun Nov 11, 2018 11:57 am, edited 1 time in total.

schmerlo
Posts: 10
Joined: Wed Nov 07, 2018 10:35 am

Re: Multiple Frame buffer beta testers wanted

Fri Nov 09, 2018 9:21 am

jamesh wrote:
Thu Nov 08, 2018 2:42 pm

delete (commend-out) commands mentioned below:

Code: Select all

framebuffer_width=854
framebuffer_height=480
display_default_lcd=0 

Code: Select all

hdmi_timings=854 0 14 4 12 480 0 2 3 9 0 0 0 60 0 32000000 3 
this is no longer valid for DPI as we now have a dpi_timings command. As it now screws up your HDMI timing (thanks to jamesh we have consistent naming now ) change to

Code: Select all

dpi_timings=854 0 14 4 12 480 0 2 3 9 0 0 0 60 0 32000000 3  
framebbuffer size will be used from the dpi_timings line, default display is selected via frambuffer_priority command.

Overscan schould be removed; if you have black borders on DPI your timing is trash.

Report back if these changes do the trick.

Just for sanity check: you have changed 99-fbturbo.conf entry and you're using the correct modukes (rpi-update xx as described starting from here viewtopic.php?f=63&t=216399&start=225#p1381675)?
Changed the timings line and removed the overscan and width/height. Still hangs at early boot. I did a rpi-update 0018be6 to update to the corresponding boot files from the raspberry repositority. I tried it on a different rpi zero as well. Same result ;( Here is the the sha256 of my
fixup_x.dat: 04824f9fad579159d367275b80f0e86095aa659ff00881a7205ba66b534453f2

aBUGSworstnightmare
Posts: 1349
Joined: Tue Jun 30, 2015 1:35 pm

Re: Multiple Frame buffer beta testers wanted

Fri Nov 09, 2018 10:05 am

schmerlo wrote:
Fri Nov 09, 2018 9:21 am
jamesh wrote:
Thu Nov 08, 2018 2:42 pm

delete (commend-out) commands mentioned below:

Code: Select all

framebuffer_width=854
framebuffer_height=480
display_default_lcd=0 

Code: Select all

hdmi_timings=854 0 14 4 12 480 0 2 3 9 0 0 0 60 0 32000000 3 
this is no longer valid for DPI as we now have a dpi_timings command. As it now screws up your HDMI timing (thanks to jamesh we have consistent naming now ) change to

Code: Select all

dpi_timings=854 0 14 4 12 480 0 2 3 9 0 0 0 60 0 32000000 3  
framebbuffer size will be used from the dpi_timings line, default display is selected via frambuffer_priority command.

Overscan schould be removed; if you have black borders on DPI your timing is trash.

Report back if these changes do the trick.

Just for sanity check: you have changed 99-fbturbo.conf entry and you're using the correct modukes (rpi-update xx as described starting from here viewtopic.php?f=63&t=216399&start=225#p1381675)?
Changed the timings line and removed the overscan and width/height. Still hangs at early boot. I did a rpi-update 0018be6 to update to the corresponding boot files from the raspberry repositority. I tried it on a different rpi zero as well. Same result ;( Here is the the sha256 of my
fixup_x.dat: 04824f9fad579159d367275b80f0e86095aa659ff00881a7205ba66b534453f2
After the 'rpi-update 0018be6' you need to copy start_x and kernel to uSD card again (as rpi-update will replace them with the latest versions).
If I have some time to spare I can check with a Pi Zero + HDMI screen on the weekend.
Nevertheless, as you need to have memory for two framebuffers now, make sure you've increased memory size available to the GPU.

schmerlo
Posts: 10
Joined: Wed Nov 07, 2018 10:35 am

Re: Multiple Frame buffer beta testers wanted

Fri Nov 09, 2018 3:53 pm

jamesh wrote:
Thu Nov 08, 2018 2:42 pm
After the 'rpi-update 0018be6' you need to copy start_x and kernel to uSD card again (as rpi-update will replace them with the latest versions).
If I have some time to spare I can check with a Pi Zero + HDMI screen on the weekend.
Nevertheless, as you need to have memory for two framebuffers now, make sure you've increased memory size available to the GPU.
Thats what i did. Here are my sha256 hashes for the start_x.elf and kernel7.img

4a32b141fbf47aca7d48d08492c28b4c77d72d90ca0600a97c588a7473cf712d start_x.elf
793e793afec5fff62727f79e7ea43b12f0f501e0102ff40079a172b9ebecb1c8 kernel7.img

And i added gpu_mem=256 to my config.txt, same problem

aBUGSworstnightmare
Posts: 1349
Joined: Tue Jun 30, 2015 1:35 pm

Re: Multiple Frame buffer beta testers wanted

Sat Nov 10, 2018 3:52 pm

o.K. tested with a zero and see the same problem here.

After copying the 'kernel7.img' and 'start_x.elf' - 4.14.76 Versions - to the uSd card booting fails (green LED stays on continuously).

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 22684
Joined: Sat Jul 30, 2011 7:41 pm

Re: Multiple Frame buffer beta testers wanted

Sat Nov 10, 2018 4:11 pm

aBUGSworstnightmare wrote:
Sat Nov 10, 2018 3:52 pm
o.K. tested with a zero and see the same problem here.

After copying the 'kernel7.img' and 'start_x.elf' - 4.14.76 Versions - to the uSd card booting fails (green LED stays on continuously).
I can only assume its a memory issue, that's the only real differencefrom the firmwares point of view AIUI.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

aBUGSworstnightmare
Posts: 1349
Joined: Tue Jun 30, 2015 1:35 pm

Re: Multiple Frame buffer beta testers wanted

Sat Nov 10, 2018 5:21 pm

I've assigned 128MB and later 208MB to the GPU.

Zero W is not booting at all, a Raspberry 3 runs fine with that uSD. Second framebuffer is not enabled yet (max_framebuffers=1), DPI is not enabled too, so only one display connected to HDMI.

That's why I would guess it's something different, not memory. Or why should this need more RAM as a the latest official relase when configured like this?

You can do the same test quite easy as you only need the Zero+HDMI display.
If this works for you let me have kernel and start_x and I will do the test again, with HDMI only (that's where it fails already for me atm). If this works I will add a DPI display (Adafruit 5in+Kippah because you have this available too)

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 22684
Joined: Sat Jul 30, 2011 7:41 pm

Re: Multiple Frame buffer beta testers wanted

Sat Nov 10, 2018 6:13 pm

I'll try and find some time to look at this on Monday. Probably not long to see what happening once I have the VC4 debugger attached.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

DirkS
Posts: 9838
Joined: Tue Jun 19, 2012 9:46 pm
Location: Essex, UK

Re: Multiple Frame buffer beta testers wanted

Sat Nov 10, 2018 7:14 pm

jamesh wrote:
Sat Nov 10, 2018 4:11 pm
aBUGSworstnightmare wrote:
Sat Nov 10, 2018 3:52 pm
o.K. tested with a zero and see the same problem here.

After copying the 'kernel7.img' and 'start_x.elf' - 4.14.76 Versions - to the uSd card booting fails (green LED stays on continuously).
I can only assume its a memory issue, that's the only real differencefrom the firmwares point of view AIUI.
Eh... doesn't the Zero uses kernel.img instead of kernel7.img (no question mark as it's more of a statement)

TomHulmeUK
Posts: 3
Joined: Wed Jul 20, 2016 8:07 pm
Location: Blackpool, UK
Contact: Website Twitter YouTube

Re: Multiple Frame buffer beta testers wanted

Sun Nov 11, 2018 2:09 am

Hi all,

Been playing around with this multi framebuffer kernel and I find it really impressive.
Have got a question though. I've got a DSI touchscreen (the official Pi one) and an HDMI display connected.
They both work fine with the MultiheadTurbo option but the touchscreen controls the HDMI framebuffer's mouse.

Can we swap that at all so the mouse isn't being controlled on the wrong screen? I'm wanting to create a dual screen car interface for my simulator and have a touchscreen for controls within the game and this would be perfect, but the touch controls the mouse on the HDMI side of things.

-Tom

aBUGSworstnightmare
Posts: 1349
Joined: Tue Jun 30, 2015 1:35 pm

Re: Multiple Frame buffer beta testers wanted

Sun Nov 11, 2018 8:28 am

TomHulmeUK wrote:
Sun Nov 11, 2018 2:09 am
Hi all,

Been playing around with this multi framebuffer kernel and I find it really impressive.
Have got a question though. I've got a DSI touchscreen (the official Pi one) and an HDMI display connected.
They both work fine with the MultiheadTurbo option but the touchscreen controls the HDMI framebuffer's mouse.

Can we swap that at all so the mouse isn't being controlled on the wrong screen? I'm wanting to create a dual screen car interface for my simulator and have a touchscreen for controls within the game and this would be perfect, but the touch controls the mouse on the HDMI side of things.

-Tom
have you tested below already?
1. Run 'xinput list' command
This will list your input devices i.e.like
[email protected]aspberrypi:~ $ xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ PixArt USB Optical Mouse id=8 [slave pointer (2)]
⎜ ↳ FT5406 memory based driver id=9 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ USB Keyboard id=6 [slave keyboard (3)]
↳ USB Keyboard id=7 [slave keyboard (3)]
with id=9 beeing the official 7in touch (note: id is valid for this example only!)

2. Run 'xrandr' command to get a list of your output devices

3. Run 'xinput map-to-output <device> <output>' command
<device> = touch input id# = 9 (for this example)
<output> = name of your HDMI screen

TomHulmeUK
Posts: 3
Joined: Wed Jul 20, 2016 8:07 pm
Location: Blackpool, UK
Contact: Website Twitter YouTube

Re: Multiple Frame buffer beta testers wanted

Sun Nov 11, 2018 12:06 pm

aBUGSworstnightmare wrote:
Sun Nov 11, 2018 8:28 am
TomHulmeUK wrote:
Sun Nov 11, 2018 2:09 am
Hi all,

Been playing around with this multi framebuffer kernel and I find it really impressive.
Have got a question though. I've got a DSI touchscreen (the official Pi one) and an HDMI display connected.
They both work fine with the MultiheadTurbo option but the touchscreen controls the HDMI framebuffer's mouse.

Can we swap that at all so the mouse isn't being controlled on the wrong screen? I'm wanting to create a dual screen car interface for my simulator and have a touchscreen for controls within the game and this would be perfect, but the touch controls the mouse on the HDMI side of things.

-Tom
have you tested below already?
1. Run 'xinput list' command
This will list your input devices i.e.like
[email protected]:~ $ xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ PixArt USB Optical Mouse id=8 [slave pointer (2)]
⎜ ↳ FT5406 memory based driver id=9 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ USB Keyboard id=6 [slave keyboard (3)]
↳ USB Keyboard id=7 [slave keyboard (3)]
with id=9 beeing the official 7in touch (note: id is valid for this example only!)

2. Run 'xrandr' command to get a list of your output devices

3. Run 'xinput map-to-output <device> <output>' command
<device> = touch input id# = 9 (for this example)
<output> = name of your HDMI screen
Hi,

I'll give that a try now! Forgot about xinput being a thing lol.

EDIT: I've just tried and both XInput and XRandR are giving me "Unable to connect to X Server".
Now, I can do

Code: Select all

export DISPLAY=:0.0
for HDMI and

Code: Select all

export DISPLAY=:0.1
for the touchscreen, but this only allows me to see one display at a time in the list, instead of all.

Any ideas?

-Tom

aBUGSworstnightmare
Posts: 1349
Joined: Tue Jun 30, 2015 1:35 pm

Re: Multiple Frame buffer beta testers wanted

Sun Nov 11, 2018 12:27 pm

Sorry, my fault! Just noted that 'xrandr' is not working on Raspbian.

What is your current setting for framebuffer_priority?

If you change this to 'framebuffer_priority=0' your desktop should be on your DSI screen.
Can you please test and report back

TomHulmeUK
Posts: 3
Joined: Wed Jul 20, 2016 8:07 pm
Location: Blackpool, UK
Contact: Website Twitter YouTube

Re: Multiple Frame buffer beta testers wanted

Sun Nov 11, 2018 12:36 pm

aBUGSworstnightmare wrote:
Sun Nov 11, 2018 12:27 pm
Sorry, my fault! Just noted that 'xrandr' is not working on Raspbian.

What is your current setting for framebuffer_priority?

If you change this to 'framebuffer_priority=0' your desktop should be on your DSI screen.
Can you please test and report back
Hiya,

I'm currently reflashing with a full desktop version of Raspbian, so give me a few minutes.
Last time I tried it put the desktop on the DSI display, but the touch was still moving the mouse on the wrong display.

EDIT:
I have reflashed, and used the latest kernel7.img and start_x.elf with the update that supports it. I now have two screens again but the touchscreen still controls the HDMI mouse, even though this is in the config:

Code: Select all

max_framebuffers=2

# x = 0 LCD, 2 for HDMI
# MAIN_LCD 0
# AUX_LCD 1
# HDMI 2
# SDTV 3

framebuffer_priority=0
The main display is the DSI now, the menu bar is on there, but the mouse moves on the HDMI display.

EDIT 2:
The mouse actually moves across both displays. It's so weird. I think XInput has been set to use both displays for the touchscreen, as if it's an absolute-mode mouse.

Image

-Tom

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 22684
Joined: Sat Jul 30, 2011 7:41 pm

Re: Multiple Frame buffer beta testers wanted

Sun Nov 11, 2018 1:02 pm

DirkS wrote:
Sat Nov 10, 2018 7:14 pm
jamesh wrote:
Sat Nov 10, 2018 4:11 pm
aBUGSworstnightmare wrote:
Sat Nov 10, 2018 3:52 pm
o.K. tested with a zero and see the same problem here.

After copying the 'kernel7.img' and 'start_x.elf' - 4.14.76 Versions - to the uSd card booting fails (green LED stays on continuously).
I can only assume its a memory issue, that's the only real differencefrom the firmwares point of view AIUI.
Eh... doesn't the Zero uses kernel.img instead of kernel7.img (no question mark as it's more of a statement)
Yes, you are right. And simply renaming kernel7 to kernel won;t work on the Zero.

I'll need to build a version for the ARMv6 cores.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

User avatar
DougieLawson
Posts: 35347
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
Contact: Website Twitter

Re: Multiple Frame buffer beta testers wanted

Sun Nov 11, 2018 3:00 pm

jamesh wrote:
Sun Nov 11, 2018 1:02 pm
I'll need to build a version for the ARMv6 cores.
Can you build on 4.14.79 https://github.com/Hexxeh/rpi-firmware/ ... 16190b1b5d (and if you're feeling very kind on 4.19.1 https://github.com/Hexxeh/rpi-firmware/ ... 04ef42d865)?
Note: Having anything remotely humorous in your signature is completely banned on this forum.

Any DMs sent on Twitter will be answered next month.

This is a doctor free zone.

aBUGSworstnightmare
Posts: 1349
Joined: Tue Jun 30, 2015 1:35 pm

Re: Multiple Frame buffer beta testers wanted

Sun Nov 11, 2018 6:10 pm

TomHulmeUK wrote:
Sun Nov 11, 2018 12:36 pm
aBUGSworstnightmare wrote:
Sun Nov 11, 2018 12:27 pm
Sorry, my fault! Just noted that 'xrandr' is not working on Raspbian.

What is your current setting for framebuffer_priority?

If you change this to 'framebuffer_priority=0' your desktop should be on your DSI screen.
Can you please test and report back
Hiya,

I'm currently reflashing with a full desktop version of Raspbian, so give me a few minutes.
Last time I tried it put the desktop on the DSI display, but the touch was still moving the mouse on the wrong display.

EDIT:
I have reflashed, and used the latest kernel7.img and start_x.elf with the update that supports it. I now have two screens again but the touchscreen still controls the HDMI mouse, even though this is in the config:

Code: Select all

max_framebuffers=2

# x = 0 LCD, 2 for HDMI
# MAIN_LCD 0
# AUX_LCD 1
# HDMI 2
# SDTV 3

framebuffer_priority=0
The main display is the DSI now, the menu bar is on there, but the mouse moves on the HDMI display.

EDIT 2:
The mouse actually moves across both displays. It's so weird. I think XInput has been set to use both displays for the touchscreen, as if it's an absolute-mode mouse.

Image

-Tom
disable overscan as you have black borders on HDMI

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 22684
Joined: Sat Jul 30, 2011 7:41 pm

Re: Multiple Frame buffer beta testers wanted

Sun Nov 11, 2018 9:27 pm

DougieLawson wrote:
Sun Nov 11, 2018 3:00 pm
jamesh wrote:
Sun Nov 11, 2018 1:02 pm
I'll need to build a version for the ARMv6 cores.
Can you build on 4.14.79 https://github.com/Hexxeh/rpi-firmware/ ... 16190b1b5d (and if you're feeling very kind on 4.19.1 https://github.com/Hexxeh/rpi-firmware/ ... 04ef42d865)?
the Linux side code is OSS, you anyone can rebuild the required kernel. The current firmware shoudl work with any kernel.

That said, will try to do this tomorrow.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

aBUGSworstnightmare
Posts: 1349
Joined: Tue Jun 30, 2015 1:35 pm

Re: Multiple Frame buffer beta testers wanted

Mon Nov 12, 2018 11:39 am

@jamesh: standing by, waiting for an update. Will now test with a Zero as well (HDMI+DPI) as I've only made testing based on RPi3B/3B+/CM3L so far (and initial test with Zero failed)

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 22684
Joined: Sat Jul 30, 2011 7:41 pm

Re: Multiple Frame buffer beta testers wanted

Mon Nov 12, 2018 1:03 pm

4.14.79 Pi2/3 kernel here

https://drive.google.com/open?id=1az7UR ... JDyTDFBDu7

Just building a Zero one, will post link here when done.

Edit: And here it is.

https://drive.google.com/open?id=1raO_X ... pw5cqs8ECR

I have not tested either of these, so good luck....

Now off to do a 4.19.1 version.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

aBUGSworstnightmare
Posts: 1349
Joined: Tue Jun 30, 2015 1:35 pm

Re: Multiple Frame buffer beta testers wanted

Mon Nov 12, 2018 1:46 pm

jamesh wrote: 4.14.79 Pi2/3 kernel here

https://drive.google.com/open?id=1az7UR ... JDyTDFBDu7

Just building a Zero one, will post link here when done.

Edit: And here it is.

https://drive.google.com/open?id=1raO_X ... pw5cqs8ECR

I have not tested either of these, so good luck....

Now off to do a 4.19.1 version.
Did a brief test with kernel7 - 4.14.79 - on a RPi 3B+ --> looks good so far. Only weird thing is the power supply icon in the task bar (as reported earlier alreday).
Will test Zero version in the evening (as I don't have the miniHDMI cable with me)

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 22684
Joined: Sat Jul 30, 2011 7:41 pm

Re: Multiple Frame buffer beta testers wanted

Mon Nov 12, 2018 2:41 pm

4.19.1 Version, kernel only, no modules, you'll have to sort those out yourself. Note, 4.19 is a next kernel, you should only need these if you are beta testing the new kernel. Please use the version in the previous post for the current kernel.

Pi2/3

https://drive.google.com/open?id=1iH6kt ... BlfhnH9Ll1

Zeros, Pi1, CM1

https://drive.google.com/open?id=1mvZ77 ... aWfcvHOBaY
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

Return to “General discussion”