Mailing Lists: April 2021

Monday, 26 April 2021

[gccsdk] Patch to build GCC for ARM Linux

Index: recipe/patches/gcc/gcc.config.arm.arm.h.p
===================================================================
--- recipe/patches/gcc/gcc.config.arm.arm.h.p (revision 7558)
+++ recipe/patches/gcc/gcc.config.arm.arm.h.p (working copy)
@@ -1,6 +1,6 @@
Index: gcc/config/arm/arm.h
===================================================================
---- gcc/config/arm/arm.h (revision 210657)
+--- gcc/config/arm/arm.h (revision 280157)
+++ gcc/config/arm/arm.h (working copy)
@@ -203,7 +203,7 @@
: TARGET_TPCS_FRAME)
@@ -158,16 +158,23 @@

#define ARM_REG_OK_FOR_INDEX_P(X) \
((REGNO (X) <= LAST_ARM_REGNUM \
-@@ -2194,7 +2226,7 @@
+@@ -2194,8 +2226,13 @@
an ARM chip. */
#if defined(__arm__)
extern const char *host_detect_local_cpu (int argc, const char **argv);
-# define EXTRA_SPEC_FUNCTIONS \
-+# define EXTRA_SPEC_FUNCTIONS SUBTARGET_EXTRA_SPEC_FUNCTIONS \
- { "local_cpu_detect", host_detect_local_cpu },
+- { "local_cpu_detect", host_detect_local_cpu },
++# ifdef SUBTARGET_EXTRA_SPEC_FUNCTIONS
++# define EXTRA_SPEC_FUNCTIONS SUBTARGET_EXTRA_SPEC_FUNCTIONS \
++ { "local_cpu_detect", host_detect_local_cpu },
++# else
++# define EXTRA_SPEC_FUNCTIONS \
++ { "local_cpu_detect", host_detect_local_cpu },
++# endif

# define MCPU_MTUNE_NATIVE_SPECS \
-@@ -2202,9 +2234,16 @@
+ " %{march=native:%<march=native %:local_cpu_detect(arch)}" \
+@@ -2202,9 +2239,16 @@
" %{mcpu=native:%<mcpu=native %:local_cpu_detect(cpu)}" \
" %{mtune=native:%<mtune=native %:local_cpu_detect(tune)}"
#else

Attached is a patch that allows building GCC for ARM Linux. This has been tested on a Raspberry Pi 3B, but should work on other ARM platforms as well.

Regards

Cameron

Sunday, 25 April 2021

Re: antiClickJack

On 25 Apr 2021 as I do recall,
Brian Jordan wrote:

> On 25 Apr, brian.jordan9@btinternet.com wrote:
> > In article <0f08bf2259.harriet@bazleyfamily.co.uk>,
> > Harriet Bazley <lists@bazleyfamily.co.uk> wrote:
>
> > [Snip]
>
> > > <STYLE id="antiClickjack">body{display:none !important;}</STYLE>
> > > which has the effect of hiding the entire content of the page.
>
> > [Snip]
>
> > Great find, thank you.
> > B
>
> My interest piqued I have been looking at this and discovered (I say
> 'discovered' while suspecting this is well known) that using NetSurf's
> Full save facility produces a page which can be opened.

That's interesting - the 'index' page in the Full save is actually
missing the offending line. NetSurf has somehow stripped it out (along
with rewriting a few other things, e.g. wrapping multi-line
class definitions onto a single line and apparently changing the case of
the <script> tags).

The original source HTML reads:

<script>

// for testing instart:
// window.I11C = {};
// window.I11C.Morph = 1;
</script>

<style id="antiClickjack">body{display:none !important;}</style>
<script type="text/javascript">
if (self === top) {
var antiClickjack = document.getElementById("antiClickjack");
antiClickjack.parentNode.removeChild(antiClickjack);
} else {
top.location = self.location;
}

and this gets rewritten during the Full Save process to

<SCRIPT>

// for testing instart:
// window.I11C = {};
// window.I11C.Morph = 1;
</SCRIPT>

<SCRIPT type="text/javascript">
if (self === top) {
var antiClickjack = document.getElementById("antiClickjack");
antiClickjack.parentNode.removeChild(antiClickjack);
} else {
top.location = self.location;
}

I'm not clear why this would happen while parsing the page header, so
the fact that it happens to cause the page to render as visible may be
just a massive coincidence...!

--
Harriet Bazley == Loyaulte me lie ==

Positive: Mistaken at the top of one's voice.
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Re: antiClickJack

On 25 Apr, brian.jordan9@btinternet.com wrote:
> In article <0f08bf2259.harriet@bazleyfamily.co.uk>,
> Harriet Bazley <lists@bazleyfamily.co.uk> wrote:

> [Snip]

> > <STYLE id="antiClickjack">body{display:none !important;}</STYLE>
> > which has the effect of hiding the entire content of the page.

> [Snip]

> Great find, thank you.
> B

My interest piqued I have been looking at this and discovered (I say
'discovered' while suspecting this is well known) that using NetSurf's
Full save facility produces a page which can be opened. The layout is
something of a dog's breakfast and all pictures are pixellated but the
links I have tried so far work and lead to nicely laid out pages which
NetSurf is happy with.

Stuffed Eggs Béarnaise anyone?

'If a web page fails to render in Netsurf try a full save' now added to
my 'Things to Try' notes

NetSurf test builds 5278 and 5286

B

--
_____________________________________________________________________

Brian Jordan
RISC OS 5.28 on Raspberry Pi
_____________________________________________________________________
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Re: antiClickJack

In article <0f08bf2259.harriet@bazleyfamily.co.uk>,
Harriet Bazley <lists@bazleyfamily.co.uk> wrote:

[Snip]

> <STYLE id="antiClickjack">body{display:none !important;}</STYLE>
> which has the effect of hiding the entire content of the page.

[Snip]

Great find, thank you.
B

--
_____________________________________________________________________

Brian Jordan
RISC OS 5.28 on Raspberry Pi
_____________________________________________________________________
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

antiClickJack

I've just managed to work out why at least one of the pages I've
encountered displays as completely blank in NetSurf, despite appearing
to have a good deal of basic HTML content in addition to all its scripts
etc:
https://www.chowhound.com/food-news/194075/how-to-use-bearnaise-sauce-on-practically-everything/
contains the header line
<STYLE id="antiClickjack">body{display:none !important;}</STYLE>
which has the effect of hiding the entire content of the page.

Apparently this is intended as a means of preventing pages from being
displayed in iframes, and is assumed to be overridden by a piece of
JavaScript elsewhere in the page source which will remove the display:
none if the current window is the topmost element. However, this
doesn't work at all in NetSurf's JavaScript support (even if the browser
window *is* top of the stack, which in the case of a RISC OS desktop it
often isn't!)

--
Harriet Bazley == Loyaulte me lie ==

The fact that you're paranoid.... doesn't mean they're NOT out to get you.
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Sunday, 18 April 2021

Re: [gccsdk] Any chance of a newer GCC version than 4.7.4?

On 17/04/2021 20:34, Chris Johns wrote:
> It's a bit of a push to call what the Norcroft C++ compiler complies
> "C++" ... it was old at the time.
>
> Hijacking the thread a bit (sorry) .. I guess for ELF dynamically linked
> stuff GCC 10 would be fine?

Yes, GCC 10 does work well when ELF dynamic linking. Static linking
is currently broken and I'm still thinking about how to fix that.

As for modules, it's actually RISC OS modules that it lacks support for.
Apparently, the new C++ modules are a compile time alternative to header
files and I've not had any experience of those.

Lee.

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Saturday, 17 April 2021

Re: [gccsdk] Any chance of a newer GCC version than 4.7.4?

It's a bit of a push to call what the Norcroft C++ compiler complies
"C++" ... it was old at the time.

Hijacking the thread a bit (sorry) .. I guess for ELF dynamically linked
stuff GCC 10 would be fine?

Cheers

Chris

On 17/04/2021 20:14, Terje Slettebø wrote:
> Hi Lee.
>
> Thanks for your fast reply. I figured that it was due to language and
> library changes, and for sure, C++20 has a lot of changes, such as
> modules, that you mention.
>
> Maybe a more workable solution could be to target a GCC version with
> C++17, as to my knowledge, C++ doesn't introduce features up to that
> version that affects the source code organisation.
>
> I don't have any experience with building GCC, so I think I'll settle
> with the current version, and it appears to have a quite decent
> implementation of C++11.
>
> I appreciate all the work you guys are putting into this project, as
> it gives people like me a chance to use _real_ C++, as opposed to the
> pre-standardisation version of C++ of the Norcroft compiler.
>
> Terje
>
> ------ Original Message ------
> From: "Lee Noar" <lee.noar@sky.com>
> To: gcc@gccsdk.riscos.info
> Sent: 17/04/2021 20:53:41
> Subject: Re: [gccsdk] Any chance of a newer GCC version than 4.7.4?
>
>> On 17/04/2021 18:34, Terje Slettebø wrote:
>>> Hi all.
>>>
>>> I'm new to this list, and apologies if this has been asked before (I
>>> checked the archive). I notice that the current version of GCC for
>>> RISC OS, while built relatively recently, is based on a version of
>>> GCC from 2014 (https://gcc.gnu.org/releases.html
>>> <https://gcc.gnu.org/releases.html>).
>>>
>>> Is there any reason why we're basing it on such an old version, and
>>> is there any chance of getting a later one, preferably based on the
>>> latest GCC version?
>>>
>>> I'm developing C++ applications, and a lot has changed since 2014,
>>> and even then, the GCC version only included a partial
>>> implementation of C++11. Thus, we're missing several major revisions
>>> of the C++ standard: C++11, C++14, C++17 and C++20
>>
>> If you don't mind building it yourself, then GCC 10.2.0 is in the
>> autobuilder at autobuilder/develop/gcc. Unfortunately, it's not
>> quite ready for general release as I've found the static archives
>> for libgcc and libstdc++ contain PIC code and the hack I used in
>> GCC 4.7.4 to get around that doesn't seem to be working.
>>
>> Also, it's not yet a suitable replacement for GCC 4.7.4 because
>> it doesn't support module code or libscl, both of which will
>> require a multilib build which is another complication I
>> haven't got round to yet.
>>
>> However, if you don't mind dynamic linking in the meantime,
>> then it is more than usable. I've used it extensively to compile
>> around 50 libraries including webkit which is quite demanding in its
>> use of modern C++ features. There is also a native RISC OS version.
>> The issue then is how to distribute the libraries, as we don't
>> have an official download yet. We can't really offer the libraries
>> without the compiler and, well, I need to get those static archives
>> fixed.
>>
>> I see that GCC 10.3.0 has been released and if GCC 11 isn't
>> forthcoming, then I may upgrade it to that soon.
>>
>> Lee.
>>
>> _______________________________________________
>> GCCSDK mailing list gcc@gccsdk.riscos.info
>> Bugzilla: http://www.riscos.info/bugzilla/index.cgi
>> List Info: http://www.riscos.info/mailman/listinfo/gcc
>> Main Page: http://www.riscos.info/index.php/GCCSDK
>
>
> _______________________________________________
> GCCSDK mailing list gcc@gccsdk.riscos.info
> Bugzilla: http://www.riscos.info/bugzilla/index.cgi
> List Info: http://www.riscos.info/mailman/listinfo/gcc
> Main Page: http://www.riscos.info/index.php/GCCSDK

--
This email has been checked for viruses by AVG.
https://www.avg.com

Re: [gccsdk] Any chance of a newer GCC version than 4.7.4?

Hi Lee.

Thanks for your fast reply. I figured that it was due to language and
library changes, and for sure, C++20 has a lot of changes, such as
modules, that you mention.

Maybe a more workable solution could be to target a GCC version with
C++17, as to my knowledge, C++ doesn't introduce features up to that
version that affects the source code organisation.

I don't have any experience with building GCC, so I think I'll settle
with the current version, and it appears to have a quite decent
implementation of C++11.

I appreciate all the work you guys are putting into this project, as it
gives people like me a chance to use _real_ C++, as opposed to the
pre-standardisation version of C++ of the Norcroft compiler.

Terje

------ Original Message ------
From: "Lee Noar" <lee.noar@sky.com>
To: gcc@gccsdk.riscos.info
Sent: 17/04/2021 20:53:41
Subject: Re: [gccsdk] Any chance of a newer GCC version than 4.7.4?

>On 17/04/2021 18:34, Terje Slettebø wrote:
>>Hi all.
>>
>>I'm new to this list, and apologies if this has been asked before (I
>>checked the archive). I notice that the current version of GCC for
>>RISC OS, while built relatively recently, is based on a version of GCC
>>from 2014 (https://gcc.gnu.org/releases.html
>><https://gcc.gnu.org/releases.html>).
>>
>>Is there any reason why we're basing it on such an old version, and is
>>there any chance of getting a later one, preferably based on the
>>latest GCC version?
>>
>>I'm developing C++ applications, and a lot has changed since 2014, and
>>even then, the GCC version only included a partial implementation of
>>C++11. Thus, we're missing several major revisions of the C++
>>standard: C++11, C++14, C++17 and C++20
>
>If you don't mind building it yourself, then GCC 10.2.0 is in the
>autobuilder at autobuilder/develop/gcc. Unfortunately, it's not
>quite ready for general release as I've found the static archives
>for libgcc and libstdc++ contain PIC code and the hack I used in
>GCC 4.7.4 to get around that doesn't seem to be working.
>
>Also, it's not yet a suitable replacement for GCC 4.7.4 because
>it doesn't support module code or libscl, both of which will
>require a multilib build which is another complication I
>haven't got round to yet.
>
>However, if you don't mind dynamic linking in the meantime,
>then it is more than usable. I've used it extensively to compile
>around 50 libraries including webkit which is quite demanding in its
>use of modern C++ features. There is also a native RISC OS version.
>The issue then is how to distribute the libraries, as we don't
>have an official download yet. We can't really offer the libraries
>without the compiler and, well, I need to get those static archives
>fixed.
>
>I see that GCC 10.3.0 has been released and if GCC 11 isn't
>forthcoming, then I may upgrade it to that soon.
>
>Lee.
>
>_______________________________________________
>GCCSDK mailing list gcc@gccsdk.riscos.info
>Bugzilla: http://www.riscos.info/bugzilla/index.cgi
>List Info: http://www.riscos.info/mailman/listinfo/gcc
>Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] Any chance of a newer GCC version than 4.7.4?

On 17/04/2021 18:34, Terje Slettebø wrote:
> Hi all.
>
> I'm new to this list, and apologies if this has been asked before (I
> checked the archive). I notice that the current version of GCC for RISC
> OS, while built relatively recently, is based on a version of GCC from
> 2014 (https://gcc.gnu.org/releases.html
> <https://gcc.gnu.org/releases.html>).
>
> Is there any reason why we're basing it on such an old version, and is
> there any chance of getting a later one, preferably based on the latest
> GCC version?
>
> I'm developing C++ applications, and a lot has changed since 2014, and
> even then, the GCC version only included a partial implementation of
> C++11. Thus, we're missing several major revisions of the C++ standard:
> C++11, C++14, C++17 and C++20

If you don't mind building it yourself, then GCC 10.2.0 is in the
autobuilder at autobuilder/develop/gcc. Unfortunately, it's not
quite ready for general release as I've found the static archives
for libgcc and libstdc++ contain PIC code and the hack I used in
GCC 4.7.4 to get around that doesn't seem to be working.

Also, it's not yet a suitable replacement for GCC 4.7.4 because
it doesn't support module code or libscl, both of which will
require a multilib build which is another complication I
haven't got round to yet.

However, if you don't mind dynamic linking in the meantime,
then it is more than usable. I've used it extensively to compile
around 50 libraries including webkit which is quite demanding in its
use of modern C++ features. There is also a native RISC OS version.
The issue then is how to distribute the libraries, as we don't
have an official download yet. We can't really offer the libraries
without the compiler and, well, I need to get those static archives
fixed.

I see that GCC 10.3.0 has been released and if GCC 11 isn't
forthcoming, then I may upgrade it to that soon.

Lee.

[gccsdk] Any chance of a newer GCC version than 4.7.4?

Hi all.

I'm new to this list, and apologies if this has been asked before (I checked the archive). I notice that the current version of GCC for RISC OS, while built relatively recently, is based on a version of GCC from 2014 (https://gcc.gnu.org/releases.html).

Is there any reason why we're basing it on such an old version, and is there any chance of getting a later one, preferably based on the latest GCC version?

I'm developing C++ applications, and a lot has changed since 2014, and even then, the GCC version only included a partial implementation of C++11. Thus, we're missing several major revisions of the C++ standard: C++11, C++14, C++17 and C++20

Regards,

Terje

Tuesday, 13 April 2021

Re: [Rpcemu] Full screen display

In article <591a13dbb3j.mccartney@blueyonder.co.uk>, John
McCartney <j.mccartney@blueyonder.co.uk> wrote:

> > I have RPCEmu running on Debian (currently bullseye,
> > i.e. testing). I have two workspaces and RPCEmu runs
> > full screen on the second one. I can switch between
> > workspaces using Ctrl+Alt+ArrowLeft or ArrowRight or
> > use Ctrl+F1 or Ctrl+F2.

> The idea of having RPCEmu on a different workspace had
> not occurred to me. If I can resolve my current issue,
> I'll look at that.

I've just set it up and moved it to workspace 2. I wondered
if there was a way of automatically getting it to launch
into workspace 2 until I discovered that changing the
workspace *before* launching it gives me what I want.
Changing the workspace with <ctrl><alt> right/left arrows
still works and doesn't seem to interfere with RISC OS.

Before accessing RPCEmu on a different workspace, allowing
the mouse to hit the bottom of the screen popped the panel
up over the icon bar. Now, that doesn't happen and I've
been able to set the panel to be always visible without it
affecting RPCEmu in workspace 2.

So, my cup runneth over! I now have RISC OS 5 on my laptop
and VRPC is now confined to my Windows box for a specific
and limited purpose.

Thank you Frank and David for your useful suggestions and
more thanks to all involved with the development of RPCEmu.

John

--
John McCartney
j.mccartney@blueyonder.co.uk

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Sunday, 11 April 2021

Some bug fixes for the framebuffer frontend

Hi,

First of all I want to say thanks for all the hard work that has been put into this browser over the years!
I was looking for a fast and lightweight browser to port to the reMarkable, which is an E-Ink tablet with a single-core ARMv7 processor and 500MB RAM.
My efforts to get it running were successful, and I am absolutely amazed by the performance of Netsurf on this device. Really great work!

I found some bugs in the framebuffer frontend. which I have mostly fixed in my fork, but I would like to keep the changes in my fork as minimal as possible.
These fixes may not be in a fitting location, or could be improved (C programming is very new to me), but perhaps they can serve as a base for a fix that can be applied to your codebase.

- The icons in the toolbar are not resized horizontically, just vertically, when setting the toolbar height via fb_toolbar_size.
https://github.com/alex0809/netsurf-base-reMarkable/commit/134cd55cbf4d69d4fc6fb656f5b789b8623c80e7

- On-screen keyboard close button is set to static 18 pixel size, size should be dependent on fb_furniture_size instead
https://github.com/alex0809/netsurf-base-reMarkable/commit/7b6860e26c4828e08609f0dfc7a3d129c2e1dd09

- Some wrong mappings on the on-screen keyboard: slash and backslash is swapped, quote key is mapped to l key
https://github.com/alex0809/netsurf-base-reMarkable/commit/0a44646f4f8fe1a36ebc7167b0f90383853c63df

- The on-screen keyboard scrolling and page change is bugged:
When you keep the keyboard open and scroll, the image of the keyboard is scrolled as part of the content.
When you change the page, the keyboard remains in open state but new webpage content is drawn over it.
I haven't got around to fixing this yet. Hints on how to approach this are appreciated!

- This one is a bit more subtle, and I think it only becomes apparent in my more specific use case:
When scrolling via mouse-drag, the desktop/browser_window.c#browser_window_set_scroll function receives the rect to scroll to, and forwards that to set_scroll on the gui-window.
Issue is, the content size in the framebuffer frontend depends on the current scale factor, but the browser_window_set_scroll sends the new rect without the scale factor calculated in.
When continuously scrolling, like is done in the original implementation, this is not noticeable, because each scroll will only be by a few pixels.
But to adapt the scrolling for the E-Ink display, I set fixed scroll increments. And what happens is that e.g. when you set it to scroll 100 pixels, it will actually only scroll (100 / scale) pixels.
https://github.com/alex0809/netsurf-base-reMarkable/commit/8658c931c2cf6dc3260cd6939ec8fe7592227208

Regards,
Alex

Re: [Rpcemu] Full screen display

In article
<VI1PR08MB2846A7C2CD95E5C232AA3DB8D3729@VI1PR08MB2846.eurprd08.prod.outlook.com>,
David Gee <dr.david.gee@outlook.com> wrote:

> Which version of RPCEmu are you using?

0.9.3

> This used to be a problem with the 0.8.x series but I
> thought it had been avoided in the 0.9.x series, which
> uses Qt rather than Allegro to produce the interface.

I'll have to take your word for that. I only ever got as
far as installing 0.8.x ( a couple of times) but setting up
the networking proved too much trouble for me.

> I don't think I've encountered it recently, but then on
> the HP laptop that I run Linux on, I start RPCEmu up in
> full-screen mode and run it at a lower resolution than
> full-screen (which, with a native resolution of 1920 x
> 1089, results in text that is too small to read
> comfortably in RO).

How do you start it up in full-screen mode? Mine always
starts in a (relatively) small window.

> It would be surprising if two completely different
> methods of generating the UI produced the same error.

> You can probably avoid most of the use cases for coming
> out of full screen mode by moving to another virtual
> desktop. The keystrokes Frank gave work with most Linux
> desktops, but in Gnome ˜ which I use (I'm currently
> running Ubuntu 18.04 LTS) ˜ it is
> Super+PageUp/Super+PageDown.

I'll look at that when I have more time.

> If RO traps the standard keystroke you might find that
> changing to a combination involving the Super (i.e.
> Windows) key helps.

Again, when time permits.

John

--
John McCartney
j.mccartney@blueyonder.co.uk

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Saturday, 10 April 2021

Re: [Rpcemu] Full screen display

Which version of RPCEmu are you using? This used to be a problem with the 0.8.x series but I thought it had been avoided in the 0.9.x series, which uses Qt rather than Allegro to produce the interface. I don't think I've encountered it recently, but then on the HP laptop that I run Linux on, I start RPCEmu up in full-screen mode and run it at a lower resolution than full-screen (which, with a native resolution of 1920 x 1089, results in text that is too small to read comfortably in RO).

It would be surprising if two completely different methods of generating the UI produced the same error.

You can probably avoid most of the use cases for coming out of full screen mode by moving to another virtual desktop. The keystrokes Frank gave work with most Linux desktops, but in Gnome — which I use (I'm currently running Ubuntu 18.04 LTS) — it is Super+PageUp/Super+PageDown.

If RO traps the standard keystroke you might find that changing to a combination involving the Super (i.e. Windows) key helps.

David Gee

Gateshead

On 10 Apr 2021, at 07:07, Frank de Bruijn <rpcemu1-sub@aconet.org> wrote:

In article <591a7d7b09j.mccartney@blueyonder.co.uk>,
John McCartney <j.mccartney@blueyonder.co.uk> wrote:

In article <591a22ccb5rpcemu1-sub@aconet.org>, Frank de

Bruijn <rpcemu1-sub@aconet.org> wrote:

<snip>

I usually go to full screen before the desktop appears.

In that case the window ends up correctly 'centered'.

I've just tried that and it seems to work. However, if I

leave full-screen and then re-invoke it, I get the same

problem which you describe in the first quoted paragraph

above.

Yes, there's definitely a problem here.

Regards,
Frank

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Friday, 9 April 2021

Re: [Rpcemu] Full screen display

In article <591a7d7b09j.mccartney@blueyonder.co.uk>,
John McCartney <j.mccartney@blueyonder.co.uk> wrote:
> In article <591a22ccb5rpcemu1-sub@aconet.org>, Frank de
> Bruijn <rpcemu1-sub@aconet.org> wrote:

> <snip>

> > I usually go to full screen before the desktop appears.
> > In that case the window ends up correctly 'centered'.

> I've just tried that and it seems to work. However, if I
> leave full-screen and then re-invoke it, I get the same
> problem which you describe in the first quoted paragraph
> above.

Yes, there's definitely a problem here.

Regards,
Frank

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Full screen display

In article <591a22ccb5rpcemu1-sub@aconet.org>, Frank de
Bruijn <rpcemu1-sub@aconet.org> wrote:

<snip>

> Hmmm... Just tried that and I get something similar if I
> leave full screen and then go back to it. Here, the whole
> window seems to move down about half a centimeter,
> obscuring part of the icon bar. Now *that* looks like a
> bug to me.

See my last paragraph below.

> If I change my screen's 1080 height to 1044, the icon bar
> becomes fully visible again, but the top of the window is
> still a bit below where it should be.

I assume you've modified the MDF to achieve that. It's not
a route I want to go down because modifying MDFs isn't part
of my (limited) skill set.

<snip>

> I usually go to full screen before the desktop appears.
> In that case the window ends up correctly 'centered'.

I've just tried that and it seems to work. However, if I
leave full-screen and then re-invoke it, I get the same
problem which you describe in the first quoted paragraph
above.

John

--
John McCartney
j.mccartney@blueyonder.co.uk

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Thursday, 8 April 2021

Re: [Rpcemu] Full screen display

In article <591a13dbb3j.mccartney@blueyonder.co.uk>,
John McCartney <j.mccartney@blueyonder.co.uk> wrote:
> In article <591a067dbdrpcemu1-sub@aconet.org>, Frank de
> Bruijn <rpcemu1-sub@aconet.org> wrote:

> <snip>

> > > After a fresh boot, with the RPCEmu window in its default
> > > position, selecting full-screen mode from the drop-down menu
> > > results in the window losing its title bar and becoming immovable.

> > Indeed. That's what's supposed to happen in full-screen
> > mode.

> Perhaps I should be more explicit, Frank. The default position of
> RPCEmu's window is with the top left-hand corner about 1/3 of the way
> down the screen and a similar proportion across the screen. If I try
> and enter full-screen mode then, as expected, the title bar disappears
> but the window remains in its default position so that the icon bar is
> unseen below the bottom of the display and the window cannot be moved
> to bring it into view.

Hmmm... Just tried that and I get something similar if I leave full
screen and then go back to it. Here, the whole window seems to move down
about half a centimeter, obscuring part of the icon bar. Now *that*
looks like a bug to me.

> > > This happened with the default video driver even before I invoked
> > > the Nvidia 340 driver.

> > > Setting a mode with a lesser height than that of the display
> > > *does* allow full-screen mode to be used.

> > Do you mean the window's title bar stays visible in that case?
> > That's not full-screen mode.

> No. In this case the title bar disappears and the RISC OS desktop
> fills the display height.

If I change my screen's 1080 height to 1044, the icon bar becomes fully
visible again, but the top of the window is still a bit below where it
should be.

> > > You might ask why I need to enter full-screen mode if I can make
> > > it look as if that's how it is just by moving the default window
> > > to cover the screen. Well, I don't know if this is known/expected
> > > behaviour or if there is a bug (feature?) with RPCEmu.

> > Seems to work as expected.

> Not here as my expanded description above shows.

I usually go to full screen before the desktop appears. In that case the
window ends up correctly 'centered'.

Regards,
Frank

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Full screen display

In article <591a067dbdrpcemu1-sub@aconet.org>, Frank de
Bruijn <rpcemu1-sub@aconet.org> wrote:

<snip>

> > After a fresh boot, with the RPCEmu window in its
> > default position, selecting full-screen mode from the
> > drop-down menu results in the window losing its title
> > bar and becoming immovable.

> Indeed. That's what's supposed to happen in full-screen
> mode.

Perhaps I should be more explicit, Frank. The default
position of RPCEmu's window is with the top left-hand
corner about 1/3 of the way down the screen and a similar
proportion across the screen. If I try and enter
full-screen mode then, as expected, the title bar
disappears but the window remains in its default position
so that the icon bar is unseen below the bottom of the
display and the window cannot be moved to bring it into
view.

> > This happened with the default video driver even before
> > I invoked the Nvidia 340 driver.

> > Setting a mode with a lesser height than that of the
> > display *does* allow full-screen mode to be used.

> Do you mean the window's title bar stays visible in that
> case? That's not full-screen mode.

No. In this case the title bar disappears and the RISC OS
desktop fills the display height.

> > You might ask why I need to enter full-screen mode if I
> > can make it look as if that's how it is just by moving
> > the default window to cover the screen. Well, I don't
> > know if this is known/expected behaviour or if there is
> > a bug (feature?) with RPCEmu.

> Seems to work as expected.

Not here as my expanded description above shows.

> I have RPCEmu running on Debian (currently bullseye, i.e.
> testing). I have two workspaces and RPCEmu runs full
> screen on the second one. I can switch between workspaces
> using Ctrl+Alt+ArrowLeft or ArrowRight or use Ctrl+F1 or
> Ctrl+F2.

The idea of having RPCEmu on a different workspace had not
occurred to me. If I can resolve my current issue, I'll
look at that.

> That's with the Xfce4 desktop, by the way. I don't know
> if those key combinations work on your Mint's desktop
> environment.

I've just checked and they do work in just the same way.

Thanks for your input, Frank.

John

--
John McCartney
j.mccartney@blueyonder.co.uk

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Full screen display

In article <591a01ca55j.mccartney@blueyonder.co.uk>,
John McCartney <j.mccartney@blueyonder.co.uk> wrote:
> I'm running RPCEmu under Linux Mint 20.1 on a decade-old Samsung 17"
> laptop with a 1600 x 900 screen driven by an Nvidia graphics card. It
> has an i3 CPU, 8 GB of RAM and a 480 GB SSD. It runs very well indeed
> thank you very much, except...

> I can't get it to run properly in full-screen mode.

> Without selecting full-screen, I have a working 1600 x 900 mode in 16
> million colours and with a 60 Hz refresh. Using <alt>click-drag, I can
> move the window to cover the whole screen. The panel at the bottom of
> the screen is set to auto-hide.

> After a fresh boot, with the RPCEmu window in its default position,
> selecting full-screen mode from the drop-down menu results in the
> window losing its title bar and becoming immovable.

Indeed. That's what's supposed to happen in full-screen mode.

> This happened with the default video driver even before I invoked the
> Nvidia 340 driver.

> Setting a mode with a lesser height than that of the display *does*
> allow full-screen mode to be used.

Do you mean the window's title bar stays visible in that case? That's
not full-screen mode.

> You might ask why I need to enter full-screen mode if I can make it
> look as if that's how it is just by moving the default window to cover
> the screen. Well, I don't know if this is known/expected behaviour or
> if there is a bug (feature?) with RPCEmu.

Seems to work as expected. I have RPCEmu running on Debian (currently
bullseye, i.e. testing). I have two workspaces and RPCEmu runs full
screen on the second one. I can switch between workspaces using
Ctrl+Alt+ArrowLeft or ArrowRight or use Ctrl+F1 or Ctrl+F2.

That's with the Xfce4 desktop, by the way. I don't know if those key
combinations work on your Mint's desktop environment.

Regards,
Frank

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

[Rpcemu] Full screen display

I'm running RPCEmu under Linux Mint 20.1 on a decade-old
Samsung 17" laptop with a 1600 x 900 screen driven by an
Nvidia graphics card. It has an i3 CPU, 8 GB of RAM and a
480 GB SSD. It runs very well indeed thank you very much,
except...

I can't get it to run properly in full-screen mode.

Without selecting full-screen, I have a working 1600 x 900
mode in 16 million colours and with a 60 Hz refresh. Using
<alt>click-drag, I can move the window to cover the whole
screen. The panel at the bottom of the screen is set to
auto-hide.

After a fresh boot, with the RPCEmu window in its default
position, selecting full-screen mode from the drop-down
menu results in the window losing its title bar and
becoming immovable. This happened with the default video
driver even before I invoked the Nvidia 340 driver.

Setting a mode with a lesser height than that of the
display *does* allow full-screen mode to be used.

You might ask why I need to enter full-screen mode if I can
make it look as if that's how it is just by moving the
default window to cover the screen. Well, I don't know if
this is known/expected behaviour or if there is a bug
(feature?) with RPCEmu.

I can certainly live with this situation and only raise it
in case there is a remedy of which I'm unaware or, indeed,
if a remedy is at all possible.

John

--
John McCartney
j.mccartney@blueyonder.co.uk

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Monday, 5 April 2021

Re: [gccsdk] GCC on RISC OS hanging

Lee Noar wrote on 30 March 2021 14:23

> On 29/03/2021 18:57, alan buckley wrote:
> > Iï¿½ve been trying to build my packit code on RISC OS 5.24 on RPCEmu. It
> > just seems to hang. Occasionally the screen getï¿½s corrupted or an error
> > box (that I canï¿½t see properly or read) appears. Iï¿½ve no idea what is
> > causing this and Iï¿½ve not been able to eliminate anything to narrow it down.
> >
> > Smaller programs seem to compile OK.
> >
> > Any suggestion on what may be going wrong?

> Is this in a taskwindow? If you attempt it from a single tasking command
> line, does that give you a more useful error?

Still hangs (on my first attempt it crashed RPCEmu). On the second attempt

It hung but reported a missing library (which I know had been seen).

> Are you using make, perhaps for your project, but calling GCC directly
> for smaller programs; could it be make at fault rather than GCC?

I've always used make for all the programs. You could be correct about

it being make instead of GCC though as I put just the g++ link command

in an Obey file and the ran OK.

Lee.

Re: libnsgif and memory bombs

That's great, thanks Michael. I'll remove my patch and update from your repo.

On Mon, 5 Apr 2021 at 14:51, Michael Drake
<michael.drake@codethink.co.uk> wrote:
>
> Hi John,
>
> Thanks for the patch. It is an improvement and I've applied it.
> I'm currently considering moving the call to gif_initialise_sprite
> into gif_decode_frame so that the bitmap area is always created
> when a client calls gif_decode_frame. At the moment it will only
> happen for the first frame that is to be displayed, which is a
> change in behavior.
>
> I've fixed decode_gif.c to consult the display flag.
>
> By the way, your patch had tabs for indent, but that file
> (inexplicably) uses spaces. I changed the patch to use
> spaces to match but I plan to convert the whole file to
> tabs soon.
>
> Best regards,
> Michael
>
>
> On 03/04/2021 12:33, jcupitt@gmail.com wrote:
> > Here's a better version of the patch:
> >
> > https://github.com/libvips/libvips/blob/master/libvips/foreign/libnsgif/patches/delay-alloc.patch
> >
> > (removes a stray create_bitmap call)
> >
> >
> > On Fri, 2 Apr 2021 at 11:58, <jcupitt@gmail.com> wrote:
> >>
> >> Hi all,
> >>
> >> I had a thought regarding memory allocation in libnsgif.
> >>
> >> At the moment, calling `gif_initialise()` will parse the GIF file and
> >> allocate memory for rendering. You then call gif_decode_frame() to
> >> decompress and render each frame of the animation.
> >>
> >> However, this means just opening the GIF can trigger very large memory
> >> allocations, with no chance for the caller to intervene, except by
> >> putting a hard pixel limit into the bitmap_create() callback. For
> >> example, a 20 byte GIF can cause a 17gb malloc.
> >>
> >> How about delaying the allocation of the bitmap until the first call
> >> to gif_decode_frame()? This would allow the caller to check the
> >> detected width and height and apply some kind of size policy before
> >> allowing rendering to occur.
> >>
> >> Here's a possible patch that does this. It's very simple and does not
> >> affect the API, just the memory behaviour (I think):
> >>
> >> https://github.com/libvips/libvips/commit/9bdf5e8cda3e0c63584984282b1e36d97c50bb1a
> >>
> >> John
> > _______________________________________________
> > netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
> > To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org
> >
>
> --
> Michael Drake https://www.codethink.co.uk/
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Re: libnsgif and memory bombs

Hi John,

Thanks for the patch. It is an improvement and I've applied it.
I'm currently considering moving the call to gif_initialise_sprite
into gif_decode_frame so that the bitmap area is always created
when a client calls gif_decode_frame. At the moment it will only
happen for the first frame that is to be displayed, which is a
change in behavior.

I've fixed decode_gif.c to consult the display flag.

By the way, your patch had tabs for indent, but that file
(inexplicably) uses spaces. I changed the patch to use
spaces to match but I plan to convert the whole file to
tabs soon.

Best regards,
Michael

On 03/04/2021 12:33, jcupitt@gmail.com wrote:
> Here's a better version of the patch:
>
> https://github.com/libvips/libvips/blob/master/libvips/foreign/libnsgif/patches/delay-alloc.patch
>
> (removes a stray create_bitmap call)
>
>
> On Fri, 2 Apr 2021 at 11:58, <jcupitt@gmail.com> wrote:
>>
>> Hi all,
>>
>> I had a thought regarding memory allocation in libnsgif.
>>
>> At the moment, calling `gif_initialise()` will parse the GIF file and
>> allocate memory for rendering. You then call gif_decode_frame() to
>> decompress and render each frame of the animation.
>>
>> However, this means just opening the GIF can trigger very large memory
>> allocations, with no chance for the caller to intervene, except by
>> putting a hard pixel limit into the bitmap_create() callback. For
>> example, a 20 byte GIF can cause a 17gb malloc.
>>
>> How about delaying the allocation of the bitmap until the first call
>> to gif_decode_frame()? This would allow the caller to check the
>> detected width and height and apply some kind of size policy before
>> allowing rendering to occur.
>>
>> Here's a possible patch that does this. It's very simple and does not
>> affect the API, just the memory behaviour (I think):
>>
>> https://github.com/libvips/libvips/commit/9bdf5e8cda3e0c63584984282b1e36d97c50bb1a
>>
>> John
> _______________________________________________
> netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
> To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org
>

--
Michael Drake https://www.codethink.co.uk/
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Re: libnsgif and memory bombs

Thanks John,

I'll have a look at it soon.

Best regards,
Michael

On 03/04/2021 12:33, jcupitt@gmail.com wrote:
> Here's a better version of the patch:
>
> https://github.com/libvips/libvips/blob/master/libvips/foreign/libnsgif/patches/delay-alloc.patch
>
> (removes a stray create_bitmap call)
>
>
> On Fri, 2 Apr 2021 at 11:58, <jcupitt@gmail.com> wrote:
>>
>> Hi all,
>>
>> I had a thought regarding memory allocation in libnsgif.
>>
>> At the moment, calling `gif_initialise()` will parse the GIF file and
>> allocate memory for rendering. You then call gif_decode_frame() to
>> decompress and render each frame of the animation.
>>
>> However, this means just opening the GIF can trigger very large memory
>> allocations, with no chance for the caller to intervene, except by
>> putting a hard pixel limit into the bitmap_create() callback. For
>> example, a 20 byte GIF can cause a 17gb malloc.
>>
>> How about delaying the allocation of the bitmap until the first call
>> to gif_decode_frame()? This would allow the caller to check the
>> detected width and height and apply some kind of size policy before
>> allowing rendering to occur.
>>
>> Here's a possible patch that does this. It's very simple and does not
>> affect the API, just the memory behaviour (I think):
>>
>> https://github.com/libvips/libvips/commit/9bdf5e8cda3e0c63584984282b1e36d97c50bb1a
>>
>> John
> _______________________________________________
> netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
> To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org
>

--
Michael Drake https://www.codethink.co.uk/
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Saturday, 3 April 2021

Re: libnsgif and memory bombs

Here's a better version of the patch:

https://github.com/libvips/libvips/blob/master/libvips/foreign/libnsgif/patches/delay-alloc.patch

(removes a stray create_bitmap call)

On Fri, 2 Apr 2021 at 11:58, <jcupitt@gmail.com> wrote:
>
> Hi all,
>
> I had a thought regarding memory allocation in libnsgif.
>
> At the moment, calling `gif_initialise()` will parse the GIF file and
> allocate memory for rendering. You then call gif_decode_frame() to
> decompress and render each frame of the animation.
>
> However, this means just opening the GIF can trigger very large memory
> allocations, with no chance for the caller to intervene, except by
> putting a hard pixel limit into the bitmap_create() callback. For
> example, a 20 byte GIF can cause a 17gb malloc.
>
> How about delaying the allocation of the bitmap until the first call
> to gif_decode_frame()? This would allow the caller to check the
> detected width and height and apply some kind of size policy before
> allowing rendering to occur.
>
> Here's a possible patch that does this. It's very simple and does not
> affect the API, just the memory behaviour (I think):
>
> https://github.com/libvips/libvips/commit/9bdf5e8cda3e0c63584984282b1e36d97c50bb1a
>
> John
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Friday, 2 April 2021

libnsgif and memory bombs

Hi all,

I had a thought regarding memory allocation in libnsgif.

At the moment, calling `gif_initialise()` will parse the GIF file and
allocate memory for rendering. You then call gif_decode_frame() to
decompress and render each frame of the animation.

However, this means just opening the GIF can trigger very large memory
allocations, with no chance for the caller to intervene, except by
putting a hard pixel limit into the bitmap_create() callback. For
example, a 20 byte GIF can cause a 17gb malloc.

How about delaying the allocation of the bitmap until the first call
to gif_decode_frame()? This would allow the caller to check the
detected width and height and apply some kind of size policy before
allowing rendering to occur.

Here's a possible patch that does this. It's very simple and does not
affect the API, just the memory behaviour (I think):

https://github.com/libvips/libvips/commit/9bdf5e8cda3e0c63584984282b1e36d97c50bb1a

John
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org