Date   

Invalid checksums for SRC_URI ignored?

Michael Opdenacker
 

Greetings,

I reused a simple "hello" recipe and added a non-matching checksum to it:

...
SRC_URI = "file://helloworld.c"
SRC_URI[md5sum] = "34f0efd76b4f18888888888833cdd129"
...

The rest of the recipe comes from
https://git.openembedded.org/openembedded-core/tree/meta-skeleton/recipes-skeleton/hello-single.

Why doesn't Bitbake stop, reporting that the checksum doesn't match the
source file?
Anyway, why does the recipe build without a checksum? Shouldn't
checksums be mandatory?

I'm using the "master" version of Poky.

Thanks in advance
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


Re: Honister broken WiFi communication

JH
 

Hi Tomasz,

Thanks for your response.

Are you using custom Linux kernel / custom device tree? Maybe there is
some issue there?
Yes, but the Zeus build image uses the same device tree that could run
WiFi connection without any issues, I am comparing the same source and
configuration between Zeus and Honister, the only difference is the
two different OE Yocto versions.

Thank you.

Kind regards,

- jh


Re: Honister broken WiFi communication

tomzy
 

Hi JH,

Are you using custom Linux kernel / custom device tree? Maybe there is
some issue there?

 

Kind regards,
Tomasz Żyjewski
Embedded Systems Engineer
GPG: 5C495EA3EBEECA59
https://3mdeb.com | @3mdeb_com

 


[yocto-autobuilder2][PATCH] config.py: enable debian11 for hardknott

Anuj Mittal
 

Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
---
config.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config.py b/config.py
index 4c0b83b..0f99557 100644
--- a/config.py
+++ b/config.py
@@ -149,7 +149,7 @@ all_workers = workers + workers_bringup + workers_buildperf + workers_arm

# Worker filtering for older releases
workers_prev_releases = {
- "hardknott" : ("centos7", "centos8", "debian8", "debian9", "debian10", "fedora31", "fedora32", "fedora33", "fedora34", "opensuse152", "ubuntu1604", "ubuntu1804", "ubuntu2004", "perf-"),
+ "hardknott" : ("centos7", "centos8", "debian8", "debian9", "debian10", "debian11", "fedora31", "fedora32", "fedora33", "fedora34", "opensuse152", "ubuntu1604", "ubuntu1804", "ubuntu2004", "perf-"),
"gatesgarth" : ("centos7", "centos8", "debian8", "debian9", "debian10", "fedora30", "fedora31", "fedora32", "opensuse150", "opensuse151", "opensuse152", "ubuntu1604", "ubuntu1804", "ubuntu1904", "ubuntu2004", "perf-"),
"dunfell" : ("centos7", "centos8", "debian8", "debian9", "debian10", "debian11", "fedora29", "fedora30", "fedora31", "fedora32", "fedora33", "fedora34", "opensuse150", "opensuse151", "opensuse152", "ubuntu1604", "ubuntu1804", "ubuntu1904", "ubuntu2004", "perf-"),
"zeus" : ("centos7", "debian8", "debian9", "debian10", "fedora28", "fedora29", "fedora30", "opensuse150", "opensuse151", "ubuntu1604", "ubuntu1804", "ubuntu1904", "perf-"),
--
2.34.1


Re: Honister broken WiFi communication

JH
 

Hi Rudolf,

Thanks for your response and comments.

If you run ifconfig -a does your WiFi interface show up? If not there is an
issue with the driver. Use dmesg and filter for the driver. Often a driver
cannot load the firmware. What is your WiFi hardware?
Not that bad, the WiFi interfaces was fine, but it could not get dhcp
response and IP address so an automatic private IP address 169.254 was
assigned

mlan0 Link encap:Ethernet HWaddr D4:CA:6E:A4:E8:B4
inet addr:169.254.193.101 Bcast:169.254.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2 errors:0 dropped:0 overruns:0 frame:0
TX packets:56 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:330 (330.0 B) TX bytes:16392 (16.0 KiB)

I could see WiFi information well, it is not a major problem, but the
subtle issues are connman and wpa_supplicant did not set up the WiFi
driver correctly.

Connected to 34:08:04:12:b1:a2 (on mlan0)
SSID: JupiterIoT
freq: 2437
RX: 660 bytes (4 packets)
TX: 46622 bytes (129 packets)
signal: -57 dBm
rx bitrate: 1.0 MBit/s
tx bitrate: 72.2 MBit/s MCS 7 short GI

bss flags: short-slot-time
dtim period: 1
beacon int: 100

Did you install the regulatory database?
Did you mean to enable CONFIG_CFG80211_INTERNAL_REGDB? No, I did not
install it in the Zeus version either so I don't see that could be an
issue.

What error messages are you seeing when attempting to connect to a WiFi
network? Did you look at the connman logs?
No error in connman, I don't think it is connman or wpa_supplicant
issue, my suspicion is something missing in Honister built image to
prevent connman and wpa_supplicant to set up the WiFi driver
correctly.

It is not the first time I have the WiFi setup trouble to get WiFi
169.254 address, when I upgraded from Thud to Zeus, I got the exactly
the same problem that WiFi was assigned by a 169.254 address, no dhcp
response, at time, I was totally convinced it was connman issue, I
spend several months to debug connman and wpa_supplicant without any
results, then after waiting several months to pull updated Zeus again,
that problem was disappeared miraculous, that is why I suspect the
same problem in oe-core and bitbake in Honister as well.

Are there anyone in oe-core and bitbake tested connman, wpa_supplicant
for the current Honister branch? I can help to test and to debug it if
more advanced people in oe-core, bitbake, kernel, WiFi driver mwifiex
can provide me more information.

Thank you.

Kind regards,

- jupiter


Re: gdb with a broken sdk

Khem Raj
 

On 1/16/22 3:26 PM, dacav wrote:
On Wed, Jan 12, 2022 at 02:15:38AM +0000, dacav wrote:
How can I include aarch64-foobar-gdb in the devshell's PATH?
Follow up on this thread: I've been kindly helped by kroon on #yocto.
The trick consists in adding a build-time dependency to gdb-cross-aarch64
in my recipe:
DEPEND = "gdb-cross-aarch64"
perhaps gdb-cross-${TARGET_ARCH} would be more generic.

At this point I can just use `bitbake -c devshell $myrecipe` and the
debugger is available.
Bonus: the devshell turns out to be very useful as a replacement
for the SDK: the environment allows me to do the cross-compilation
with just a `make`, while earlier I needed to run `bitbake $myrecipe`
and wait several seconds.
- dacav


Re: Advertise lore.kernel.org archives on website?

Michael Opdenacker
 

On 1/18/22 12:04 PM, Richard Purdie wrote:
On Tue, 2022-01-18 at 10:44 +0100, Michael Opdenacker wrote:
Greetings,

I see more and more people using links to the lore.kernel.org archives,
for example the ones for this list: https://lore.kernel.org/yocto/

These look more convenient to use than the ones on
https://lists.yoctoproject.org/.

So what about advertising such archives on
https://www.yoctoproject.org/community/mailing-lists/, at least for the
ones which have archives on lore.kernel.org? I was thinking about just
adding an "(archives)" or "(archives / public mailbox) link at the end
of the description for each list.

What do you think?
Sounds fine to me.

Thanks for the feedback.
Done on https://www.yoctoproject.org/community/mailing-lists/

I added lore.kernel.org links when applicable, and also added the
openembedded-devel mailing list which was missing.
I could shorten "Archives / Public Inbox" by just "Public Inbox" if you
think it makes more sense.

Cheers
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


Re: Building uImage with appended DTB

Nicolas Jeker
 

On 17 Jan 2022, at 06:41, rgovostes@gmail.com wrote:

I'm a complete newcomer to Yocto, trying to translate a manual process of building software for an embedded device based on the PHYTEC phyCORE-LPC3250 SOM. I did not find an existing BSP layer for this board so I am trying to create my own.
Just a short hint if you didn’t discover it yourself, there is a (very) old BSP available from PHYTEC [1]. The downloads don’t seem to work, but they’re available on a probably forgotten FTP server [2].

[1]: https://web.archive.org/web/20120501212117/http://www.phytec.com/products/linux/bsp-LPC3180.html
[2]: ftp://ftp.phytec.com/temp/PCM-031_phyCORE-LPC3180


When I build a kernel for this device manually, I use the CONFIG_APPENDED_DTB=y option, which instructs the kernel to find the device tree right after the kernel image itself. I build the zImage, then append my DTB and finally create the uImage file:

cat arch/arm/boot/zImage ./arch/arm/boot/dts/lpc3250-phy3250.dtb > arch/arm/boot/zImage-dtb
mkimage -A arm -O linux -C none -T kernel -a 0x80008000 -e 0x80008000 -n Linux -d arch/arm/boot/zImage-dtb arch/arm/boot/uImage-dtb

I'm trying to figure out how to properly replicate this process in Yocto.

I see that Poky's meta/classes/kernel-devicetree.bbclass uses the KERNEL_DEVICETREE_BUNDLE variable to do something similar. If I have KERNEL_IMAGETYPE set to "zImage", then it will create a zImage+DTB file.

However, it expects the zImage file to be called "zImage", and the one that gets built is called "zImage-5.14.6-yocto-standard". Since it cannot find "zImage", the build fails.

cat: .../tmp/work/lpc3250-poky-linux-gnueabi/linux-yocto/5.14.6+gitAUTOINC+4f4ad2c808_7ae156be3b-r0/image/boot/zImage: No such file or directory


I also see that meta-ti has a bundle-devicetree.inc file that has a similar aim, but it deals with uImages instead.

https://git.yoctoproject.org/meta-ti/tree/recipes-kernel/linux/bundle-devicetree.inc

My concern with using this is that it appends the DTB directly to the uImage. However the uImage header structure includes a field for data size and another one for checksum. These fields are only computed correctly if the DTB is already appended before the uImage file is built.


I think if I can figure out how to make KERNEL_DEVICETREE_BUNDLE create the zImage+DTB file, then I can write a do_deploy:append() function that invokes mkimage to produce the uImage. But I'm not sure how to diagnose the problem.

Thanks,
Ryan


Yocto Project Status WW03`22

Stephen Jolley
 

Current Dev Position: YP 3.5 M2

Next Deadline: 17th Jan. 2022 YP 3.5 M2 build

 

Next Team Meetings:

 

Key Status/Updates:

  • YP 3.5 M2 is due to build this week
  • Work has progressed on inclusive language and an email should be out this week about the proposals for that after discussions amongst the volunteers who stepped up to work on it. Some obsolete variables/code have already been removed as a prelude to this.
  • Patches to switch to setuptools and away from distutils following upstream python’s lead have merered (thanks Tim!). Whilst the issues are resolved for core, work remains on other layers such as meta-oe.
  • The autobuilder does look improved from an intermittent failure perspective but we’re seeing hangs for unknown reasons on debian9 oe-selftest (seems python pthread mutex related) and on ltp on the arm worker. Sadly the open issues are at an all time high.
  • Patches to disable the network outside of do_fetch have merged.
  • Support for improved SPDX info for the kernel has merged (thanks Saul).
  • CVE issues had a bad week with further significant increases for master and stable branches. Some patches have merged to improve master (thanks Ross!).
  • Intermittent issues continue to be at record high levels and help is very much welcome in trying to resolve them. You can see the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

 

Ways to contribute:

 

YP 3.5 Milestone Dates:

  • YP 3.5 M2 build date 2022/01/17
  • YP 3.5 M2 Release date 2022/01/28
  • YP 3.5 M3 build date 2022/02/21
  • YP 3.5 M3 Release date 2022/03/04
  • YP 3.5 M4 build date 2022/04/04
  • YP 3.5 M4 Release date 2022/04/29

 

Upcoming dot releases:

  • YP 3.1.14 build date 2022/01/24
  • YP 3.1.14 Release date 2022/02/04
  • YP 3.4.2 build date 2022/02/07
  • YP 3.4.2 Release date 2022/02/18
  • YP 3.3.5 build date 2022/02/14
  • YP 3.3.5 Release date 2022/02/25
  • YP 3.1.15 build date 2022/03/14
  • YP 3.1.15 Release date 2022/03/25
  • YP 3.4.3 build date 2022/03/21
  • YP 3.4.3 Release date 2022/04/01
  • YP 3.3.6 build date 2022/03/28
  • YP 3.3.6 Release date 2022/04/08
  • YP 3.1.16 build date 2022/04/25
  • YP 3.1.16 Release date 2022/05/06

 

Tracking Metrics:

 

The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Re: Honister broken WiFi communication

Rudolf J Streif
 

Hi JH,

On Tue, Jan 18, 2022, 01:54 JH <jupiter.hce@...> wrote:
Hi,

Has anyone successfully built a Linux image by Honister to run WiFi
driver, connman and wpa_supplicant for WiFi interface?

Yes, I have, but with Network Manager instead of connman. WiFi works just fine.

I could build an image by Zeus to run WiFi driver, wpa_supplicant,
connman and dbus well, but after upgrading to Honister, the Linux
image building was fie, but the WiFi is now broken, the WiFi failed to
respond DHCP the WiFi could not connect to Internet, something is
broken between wpa_supplicant and connman which setting kernel WiFi
driver, WiFi interface and connection. I don't see any issues in
kernel WiFi driver, connman and wpa_supplicant, something missing in
the Linux image failing to set up the WiF network interface.

There are a lot of pieces in the chain and it is not obvious from your description where it is broken.

If you run ifconfig -a does your WiFi interface show up? If not there is an issue with the driver. Use dmesg and filter for the driver. Often a driver cannot load the firmware. What is your WiFi hardware?

Did you install the regulatory database?

What error messages are you seeing when attempting to connect to a WiFi network? Did you look at the connman logs?




Appreciate your comments.

Thank you.

Kind regards,

- jupiter




Re: gdb with a broken sdk

dacav
 

On Wed, Jan 12, 2022 at 02:15:38AM +0000, dacav wrote:
How can I include aarch64-foobar-gdb in the devshell's PATH?
Follow up on this thread: I've been kindly helped by kroon on #yocto.
The trick consists in adding a build-time dependency to gdb-cross-aarch64
in my recipe:

DEPEND = "gdb-cross-aarch64"

At this point I can just use `bitbake -c devshell $myrecipe` and the
debugger is available.

Bonus: the devshell turns out to be very useful as a replacement
for the SDK: the environment allows me to do the cross-compilation
with just a `make`, while earlier I needed to run `bitbake $myrecipe`
and wait several seconds.


- dacav


Re: Advertise lore.kernel.org archives on website?

Richard Purdie
 

On Tue, 2022-01-18 at 10:44 +0100, Michael Opdenacker wrote:
Greetings,

I see more and more people using links to the lore.kernel.org archives,
for example the ones for this list: https://lore.kernel.org/yocto/

These look more convenient to use than the ones on
https://lists.yoctoproject.org/.

So what about advertising such archives on
https://www.yoctoproject.org/community/mailing-lists/, at least for the
ones which have archives on lore.kernel.org? I was thinking about just
adding an "(archives)" or "(archives / public mailbox) link at the end
of the description for each list.

What do you think?
Sounds fine to me.

Cheers,

Richard


Honister broken WiFi communication

JH
 

Hi,

Has anyone successfully built a Linux image by Honister to run WiFi
driver, connman and wpa_supplicant for WiFi interface?

I could build an image by Zeus to run WiFi driver, wpa_supplicant,
connman and dbus well, but after upgrading to Honister, the Linux
image building was fie, but the WiFi is now broken, the WiFi failed to
respond DHCP the WiFi could not connect to Internet, something is
broken between wpa_supplicant and connman which setting kernel WiFi
driver, WiFi interface and connection. I don't see any issues in
kernel WiFi driver, connman and wpa_supplicant, something missing in
the Linux image failing to set up the WiF network interface.

Appreciate your comments.

Thank you.

Kind regards,

- jupiter


Advertise lore.kernel.org archives on website?

Michael Opdenacker
 

Greetings,

I see more and more people using links to the lore.kernel.org archives,
for example the ones for this list: https://lore.kernel.org/yocto/

These look more convenient to use than the ones on
https://lists.yoctoproject.org/.

So what about advertising such archives on
https://www.yoctoproject.org/community/mailing-lists/, at least for the
ones which have archives on lore.kernel.org? I was thinking about just
adding an "(archives)" or "(archives / public mailbox) link at the end
of the description for each list.

What do you think?
Cheers
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


Installing only python .pyc files onto the image #yocto

Sam
 

Was wondering if there was a way to edit the distitils3.bbclass or a similar file to only install the python .pyc files onto a yocto image?

I saw something about editing the distutils-common-base.bbclass online, however, it was only mentioned and not elaborated on.

I am currently working with a setup that installs .py files, then generates the .pyc files and removes the .py files. I am now looking for a method that will only install the .pyc files.

Any help would be appreciated.


Enhancements/Bugs closed WW03!

Stephen Jolley
 

All,

The below were the owners of enhancements or bugs closed during the last week!

Who

Count

randy.macleod@...

3

michael.opdenacker@...

1

tim.orling@...

1

richard.purdie@...

1

alexandre.belloni@...

1

Grand Total

7

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Current high bug count owners for Yocto Project 3.5

Stephen Jolley
 

All,

Below is the list as of top 44 bug owners as of the end of WW03 of who have open medium or higher bugs and enhancements against YP 3.5.   There are 71 possible work days left until the final release candidates for YP 3.5 needs to be released.

Who

Count

ross@...

37

michael.opdenacker@...

36

randy.macleod@...

23

david.reyna@...

22

bruce.ashfield@...

16

tim.orling@...

14

trevor.gamblin@...

12

sakib.sajal@...

12

richard.purdie@...

9

kai.kang@...

7

mhalstead@...

7

bluelightning@...

6

saul.wold@...

6

JPEWhacker@...

5

hongxu.jia@...

4

chee.yang.lee@...

4

kiran.surendran@...

3

Qi.Chen@...

3

jon.mason@...

3

alexandre.belloni@...

2

raj.khem@...

2

pgowda.cve@...

2

pokylinux@...

2

mshah@...

2

alejandro@...

2

open.source@...

1

yf3yu@...

1

akuster808@...

1

yi.zhao@...

1

jay.shen.teoh@...

1

limon.anibal@...

1

jonathan.richardson@...

1

aehs29@...

1

kexin.hao@...

1

matthewzmd@...

1

thomas.perrot@...

1

mark.hatle@...

1

Martin.Jansa@...

1

mingli.yu@...

1

TicoTimo@...

1

shachar@...

1

nicolas.dechesne@...

1

john.kaldas.enpj@...

1

mostthingsweb@...

1

Grand Total

260

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley
 

All,

 

The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs  Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project.  If anyone can help, please take ownership of the bug and send patches!  If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 401 unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out with these.  Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system.  There are also roughly four different "priority" classes right now,  “3.5, “3.6”, "3.99" and "Future", the more pressing/urgent issues being in "3.4" and then “3.5”.

 

Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account).  The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Re: Building uImage with appended DTB

Ryan Govostes
 

A solution that seems to work is to create a new .bbclass inherited from my layer's linux .bbappend file that implements uboot_prep_kimage:append() to append the DTB to linux.bin. This code would run at the beginning of do_uboot_mkimage() before the uImage is created.

There are a couple of prerequisites such as setting KEEPUIMAGE = "yes" and KERNEL_DEVICETREE_BUNDLE = "0".

https://gist.github.com/rgov/0628785685ab858a99c5bfca626c1d8f

I would still be curious to know why KERNEL_DEVICETREE_BUNDLE doesn't work as expected if that is supposed to be the supported method of achieving this, but my solution at least lets me move on.


[psplash][PATCH] psplash: Fix double buffering initialization

Horn, Michal
 

Some fb drivers do not implement double buffering completely or correctly.
For example mxsfb driver does not set yres_virtual to double on
initialization, nor it allows its doubling by FBIOPUT_VSCREENINFO ioctl
call. In such case, the double buffering gets enabled, but psplash fails
to display every second frame with error 'psplash_fb_flip: FBIOPAN_DISPLAY failed: Invalid argument'.
 
Panning the display by FBIOPAN_DISPLAY ioctl is always checking carefully
that the resolution, virtual buffer resolutin and offsets are in
bounds at fb_pan_display - https://elixir.bootlin.com/linux/v4.9.275/source/drivers/video/fbdev/core/fbmem.c#L891.
 
Swapping the front and back buffers is done by switching the
yoffset between 0 and yres values. For double buffering, the whole buffer
must have yres_virtual buffer size double of yres.
 
But in case of the mxsfb driver, the yres_virtual is always equal to yres,
so drawing with the offset set to yres would overrun the buffer. So the
panning is stopped and error 'Invalid argument' is returned.
 
Psplash tries to double the yres_virtual on initialization by FBIOPUT_VSCREENINFO ioctl call,
that at some point calls the mxsfb_check_var - https://elixir.bootlin.com/linux/v4.9.275/source/drivers/video/fbdev/mxsfb.c#L269
function, which for some reason always sets the yres_virtual back to yres,
effectively canceling the doubling. But no error is returned in this case,
so it gets silently ignored.

So in general, checking for the ioctl call success is not enough as some
drivers may pass this test, but fail double buffering anyway.
So now we double check the yres_virtual on fb_new and disable double
buffering in case of doubling yres_virtual fails.
 
Signed-off-by: Michal Horn <michalhorn@...>
---
 psplash-fb.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)
 
diff --git a/psplash-fb.c b/psplash-fb.c
index 2babb5f..1b73807 100644
--- a/psplash-fb.c
+++ b/psplash-fb.c
@@ -213,8 +213,18 @@ psplash_fb_new (int angle, int fbdev_id)
           perror(" Error getting the fixed framebuffer info");
           goto fail;
         } else {
-          DBG("Virtual resolution set to double");
-          fb->double_buffering = 1;
+          if (ioctl(fb->fd, FBIOPAN_DISPLAY, &fb_var) == -1) {
+            fprintf(stderr, "warning: FBIOPAN_DISPLAY failed, "
+                    "double buffering disabled\n");
+          } else {
+            if (fb_var.yres_virtual == fb_var.yres * 2) {
+              DBG("Virtual resolution set to double");
+              fb->double_buffering = 1;
+            } else {
+              fprintf(stderr, "warning: Doubling virtual "
+                      "resolution failed, double buffering disabled\n");
+            }
+          }
         }
       }
     }
-- 
2.25.1
 

1201 - 1220 of 57064