freemint-discuss — The official FreeMiNT Mailing List

Re: [Freemint-discuss] github notifications

[David G. <dga...@gm...>]

Same for me, I got the notification.

El mié, 17 ene 2024 a las 17:08, Chris Jenkins
(<cdp...@gm...>) escribió:
>
> I received the notification (I'm watching the fvdi repo in GitHub).
>
> I take it your notification didn't just end up in spam or something...?
>
> On Wed, 17 Jan 2024 at 15:33, Thorsten Otto <ad...@th...> wrote:
>>
>> Hi,
>>
>>
>> Some days ago, cyprian aka Atari260STE opened an issue in the fVDI repo. He also emailed me for this, otherwise i would not have noticed it. Does anybody know why i did not get any notification from github about this? I usually get those for all other repositories, but could not find any reason that prevents this for fVDI. And did anybody else get a notification about that new issue?
>>
>>
>> _______________________________________________
>> Freemint-discuss mailing list
>> Fre...@li...
>> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss

Re: [Freemint-discuss] github notifications

[Chris J. <cdp...@gm...>]

I received the notification (I'm watching the fvdi repo in GitHub).

I take it your notification didn't just end up in spam or something...?

On Wed, 17 Jan 2024 at 15:33, Thorsten Otto <ad...@th...> wrote:

> Hi,
>
> Some days ago, cyprian aka Atari260STE opened an issue in the fVDI repo.
> He also emailed me for this, otherwise i would not have noticed it. Does
> anybody know why i did not get any notification from github about this? I
> usually get those for all other repositories, but could not find any reason
> that prevents this for fVDI. And did anybody else get a notification about
> that new issue?
>
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>

[Freemint-discuss] github notifications

[Thorsten O. <ad...@th...>]

Hi,

Some days ago, cyprian aka Atari260STE opened an issue in the fVDI repo. He 
also emailed me for this, otherwise i would not have noticed it. Does anybody 
know why i did not get any notification from github about this? I usually get 
those for all other repositories, but could not find any reason that prevents 
this for fVDI. And did anybody else get a notification about that new issue?

Re: [Freemint-discuss] I'm having a problem with Fselect and Fpoll

[Jo E. S. <jo...@on...>]

This behaviour appears to be correct, and also something TosWin2
depends on.

Jo Even

On Wed, 2023-11-22 at 20:15 +0100, Jo Even Skarstein wrote:
> To follow up on my mail about failing shutdown. Take a look at this
> example program:
> 
> ---------------------8<----------------------
> 
> #include <mintbind.h>
> #include <stdio.h>
> 
> void main(void)
> {
> #ifndef CONSOLE
> 		long wait, f = Fcreate("u:\\pipe\\test",
> FA_SYSTEM|FA_HIDDEN);
> 		Fcntl((int)f, (long)O_NONBLOCK, F_SETFL);
> #else
> 		long wait, f = Fopen("u:\\dev\\xconout2", 2);
> #endif
> 
> 		if (f >= 0)
> 		{
> 			long c;
> 			char buf[100] = "";
> #ifdef FPOLL
> 			long poll;
> 			POLLFD pfd = {0, POLLIN, 0};
> 			pfd.fd = f;
> #endif
> 
> 			while (1)
> 			{
> #ifdef FPOLL
> 				poll = Fpoll(&pfd, 1, 100);
> 				
> 				if (poll > 0 && pfd.revents &
> POLLIN)
> 				{
> #else
> 					wait = (1 << (int) f);
> 					Fselect(100, &wait, 0L, 0L);
> #endif
> 					c = Fread((int) f, 80, buf);
> 
> 					if (c < 0)
> 					{
> 						printf("Fread
> error\n");
> 						return;
> 					}
> 				
> 					buf[(int)c] = '\0';
> 					printf(buf);
> #ifdef FPOLL
> 				}
> 				else if (poll < 0)
> 				{
> 					printf("Fpoll error\n");
> 					return;
> 				}
> #endif
> 			}
> 		}
> #ifdef CONSOLE
> 	printf("/dev/xconout2 already opened by another
> process.\n\r");
> #endif
> }
> 
> ------------->8---------------
> 
> This is a very simple program that reads data from /dev/console or a
> pipe, and prints whatever comes in to stdout. Depending on compile
> options this code produces four variants:
> 
> - Open /dev/xconout2, and waits for input with Fselect.
> - Creates a pipe /pipe/test, and waits for input with Fselect.
> - Open dev/xconout2, and waits for input with Fpoll.
> - Creates a pipe /pipe/test, and waits for input with Fselect.
> 
> In all cases the exact same things happens.
> 
> 1. Start the test-program in a TosWin window, and check CPU usage
> with
> top or the XaAES task manager. The program is waiting for
> Fselect/Fpoll
> until there is data.
> 
> 2. Write some data to dev/console or /pipe/test from another shell
> using echo or cat. Whatever you write will be displayed in the
> terminal
> where the test-program is running.
> 
> 3. Check with top and the XaAES task manager again. top will show
> that
> the test program use all available CPU, and the task manager shows
> that
> it is no longer waiting for Fselect/Fpoll. Some quick debug
> statements
> in the code shows that Fselect/Fpoll now always returns immediately,
> even when there no actual data being written to the console/pipe.
> 
> 4. Now try top > /pipe/test / top > / dev/console. Top will now show
> 0
> CPU usage, and the task manager again shows that the test program is
> mostly waiting for Fselect/Fpoll.
> 
> I can reproduce this every time on my Falcon/CT60 with a fairly
> recent
> kernel, and on my Milan060 with a kernel from 2014.
> 
> This is related to the shutdown problems I reported early. Try to
> kill
> the test-program while data is being written to the console/pipe.
> This
> is easiest to do by running top > /pipe/test, and kill the test-
> program
> from top. top will not exit, but will become unresponsive. The pipe
> is
> removed, and if you're fast enough to Control+Alt+Delete before top
> attempts to update the status again you will get this error:
> 
> pid 50 (bash): In changedrv() called from terminate, invalid fd/cwd
> FATAL ERROR. You must reboot the system.
> 
> If you just wait until top attempts to update the status the system
> just locks up solidly. No respons from mouse or keyboard, not even
> Control+Alt+Delete.
> 
> If I start the test-program that reads from /dev/xconout2 by
> shel_write
> I get the shutdown problem I explained in the previous thread, where
> shutdown halts when XaAES attempts to shut down. Maybe because of the
> debug output to the console during shutdown.
> 
> Jo Even
> 
> 
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
> 

Re: [Freemint-discuss] XaAES Scroll Click Behavior

[Joakim H. <go...@gm...>]

On 23/12/2023, Jo Even Skarstein <jo...@on...> wrote:
> On Fri, 2023-12-22 at 22:41 -0500, Mark Duckworth via Freemint-discuss
> wrote:
>> I was wondering if anyone else is as deeply offended as I am by the
>> XaAES behavior on the scrollbars specifically when you double click?
>> If you double click in the empty area OR the arrow it scrolls to the
>> maximum extent.  It makes it impossible to simply scroll a few times
>> quickly.
>
> There's atleast two of us :) I really dislike that a double-click on
> the arrow sends you to the top/bottom. When you're browsing through a
> file a bit quickly it's too easy to accidentally navigate to the ends.
> And you *have* to repeatedly click, if you click & hold you scroll to
> the end in a fraction of a seconds.

I'd certainly agree that there is sometimes (depending on
application/machine combo) a problem with CLICK + HOLD going too fast.
And as I see it, THAT would be the actual issue which should be
targetted here. Back in the days, I guess noone ever expected a scroll
action being carried out too rapidly on an Atari, but surely it could
be "capped" at a certain scroll pace.

Before adding any new settings for optional behaviour I would much
rather see the "scrolling-too-fast problem" looked into.

I use double clicks on ARROW (both left/right clicks) pretty much all
the time to speed things up and when using any other Atari environment
than XaAES and N.AES i instantly miss this feature greatly.


Regards,

/Joakim

Re: [Freemint-discuss] XaAES Scroll Click Behavior

[WongCK <won...@ya...>]

 
I normally click rapidly on arrow to scroll up/down.I normally click rapidly on slider area to page up./down.I do these because my debugging are mostly printf statements and they all goes to toswin.
Making double clicking on arrow goes to the last/top line have been slowing me down all the time.I dislike it...So I would save it to log file and debug from there.... just more steps. 
Why not just use CTRL, SHFT or ALT-click on arrow to go to top or bottom of the buffer?may be it should also not scroll down pass the end of the text (leaving many blank lines on the windows).
Just my 2 cents    On Sunday, 24 December 2023 at 07:03:30 am SGT, Mark Duckworth via Freemint-discuss <fre...@li...> wrote:  
 
 On 12/23/23 1:46 PM, Jo Even Skarstein wrote:
> On Fri, 2023-12-22 at 22:41 -0500, Mark Duckworth via Freemint-discuss
> wrote:
>> I was wondering if anyone else is as deeply offended as I am by the
>> XaAES behavior on the scrollbars specifically when you double click?
>> If you double click in the empty area OR the arrow it scrolls to the
>> maximum extent.  It makes it impossible to simply scroll a few times
>> quickly.
> 
> There's atleast two of us :) I really dislike that a double-click on
> the arrow sends you to the top/bottom. When you're browsing through a
> file a bit quickly it's too easy to accidentally navigate to the ends.
> And you *have* to repeatedly click, if you click & hold you scroll to
> the end in a fraction of a seconds.
> 
> I do like the "double-click in slider area to go to end top/bottom"
> feature though. I think it makes a lot more sense than double-clicking
> the arrows, when you repeatedly click in the slider when looking for
> something you click a lot slower than when scrolling line by line so
> you don't accidentally scroll to the end.
> 
> Jo Even
> 

It seems like a good compromise really.  Why on earth do both things 
need to instantly scroll you to the bottom on an accidental double 
click.  And I am less likely to be fast clicking the page by page scroll 
area.

Thanks,
Mark




_______________________________________________
Freemint-discuss mailing list
Fre...@li...
https://lists.sourceforge.net/lists/listinfo/freemint-discuss
  

Re: [Freemint-discuss] XaAES Scroll Click Behavior

[Mark D. <mdu...@at...>]

On 12/23/23 1:46 PM, Jo Even Skarstein wrote:
> On Fri, 2023-12-22 at 22:41 -0500, Mark Duckworth via Freemint-discuss
> wrote:
>> I was wondering if anyone else is as deeply offended as I am by the
>> XaAES behavior on the scrollbars specifically when you double click?
>> If you double click in the empty area OR the arrow it scrolls to the
>> maximum extent.  It makes it impossible to simply scroll a few times
>> quickly.
> 
> There's atleast two of us :) I really dislike that a double-click on
> the arrow sends you to the top/bottom. When you're browsing through a
> file a bit quickly it's too easy to accidentally navigate to the ends.
> And you *have* to repeatedly click, if you click & hold you scroll to
> the end in a fraction of a seconds.
> 
> I do like the "double-click in slider area to go to end top/bottom"
> feature though. I think it makes a lot more sense than double-clicking
> the arrows, when you repeatedly click in the slider when looking for
> something you click a lot slower than when scrolling line by line so
> you don't accidentally scroll to the end.
> 
> Jo Even
> 

It seems like a good compromise really.  Why on earth do both things 
need to instantly scroll you to the bottom on an accidental double 
click.  And I am less likely to be fast clicking the page by page scroll 
area.

Thanks,
Mark

Re: [Freemint-discuss] XaAES Scroll Click Behavior

[Jo E. S. <jo...@on...>]

On Fri, 2023-12-22 at 22:41 -0500, Mark Duckworth via Freemint-discuss
wrote:
> I was wondering if anyone else is as deeply offended as I am by the 
> XaAES behavior on the scrollbars specifically when you double click? 
> If you double click in the empty area OR the arrow it scrolls to the 
> maximum extent.  It makes it impossible to simply scroll a few times 
> quickly.

There's atleast two of us :) I really dislike that a double-click on
the arrow sends you to the top/bottom. When you're browsing through a
file a bit quickly it's too easy to accidentally navigate to the ends.
And you *have* to repeatedly click, if you click & hold you scroll to
the end in a fraction of a seconds.

I do like the "double-click in slider area to go to end top/bottom"
feature though. I think it makes a lot more sense than double-clicking
the arrows, when you repeatedly click in the slider when looking for
something you click a lot slower than when scrolling line by line so
you don't accidentally scroll to the end.

Jo Even

Re: [Freemint-discuss] XaAES Scroll Click Behavior

[<ps...@sc...>]

I think the behaviour is helpful for those using touchpads.

⁣Peter​

On 23 Dec 2023, 16:10, at 16:10, Mark Duckworth via Freemint-discuss <fre...@li...> wrote:
>On 12/23/23 9:03 AM, Thorsten Otto wrote:
>> On Samstag, 23. Dezember 2023 04:41:54 CET Mark Duckworth via 
>> Freemint-discuss wrote:
>> 
>>  > If you double click in the empty area OR the arrow it scrolls to
>the
>> 
>>  > maximum extent.
>> 
>> 
>> I agree with others, that behaviour is intended. You can always use 
>> single-clicks to scroll one line/page only. If you always get 
>> double-clicks, then you may have to adjust your double-click time.
>> 
>The speed with which I click the button would absolutely be considered
>a 
>double click by anyone's definition.  I simply have to learn to use 
>things differently.
>
>I still maintain though that there should be some way to quickly scroll
>
>in small increments using the mouse without unintended behavior.  I'd 
>prefer 2 separate directional arrow buttons that have the differing 
>behaviors.  And the double click should never scroll to top/bottom in 
>the empty area where the slider is not IMHO.  That should always be a 1
>
>page only scroll.
>
>The double click functionality could also be made configurable, maybe 
>even just as a build time thing so as to not reduce performance.
>
>It's funny I've always just dragged the slider to the bottom to scroll 
>to top or bottom.  I've never found that to be a big problem or 
>excessively difficult.  Clearly I am an outlier here though!
>
>Thanks,
>Mark
>
>
>
>_______________________________________________
>Freemint-discuss mailing list
>Fre...@li...
>https://lists.sourceforge.net/lists/listinfo/freemint-discuss

Re: [Freemint-discuss] XaAES Scroll Click Behavior

[<ps...@sc...>]

Somehow I missed out the word "like".  I do like the aes scroll behaviours.


Recently I was thinking about another feature I would like.

When scrolling with the mouse wheel, the page usually moves small increments.

It would be nice if control and the wheel moved a page at a time, similar to clicking on the grey area of the scroll bar.


⁣Peter​

On 23 Dec 2023, 16:04, at 16:04, Mark Duckworth <mdu...@at...> wrote:
>On 12/23/23 8:31 AM, ps...@sc... wrote:
>> I actually the double click on the arrow that scrolls to the end.  I 
>> wish windoze did it.
>> 
>> Maybe change your double click delay time ?
>> 
>> Merry Christmas,
>> 
>> Peter
>
>All I really needed is one person to say they like the behavior to 
>realize I need to find another way ;)  Indeed I can see how instant 
>scroll to bottom would be useful.
>
>Mark

Re: [Freemint-discuss] XaAES Scroll Click Behavior

[Mark D. <mdu...@at...>]

On 12/23/23 9:03 AM, Thorsten Otto wrote:
> On Samstag, 23. Dezember 2023 04:41:54 CET Mark Duckworth via 
> Freemint-discuss wrote:
> 
>  > If you double click in the empty area OR the arrow it scrolls to the
> 
>  > maximum extent.
> 
> 
> I agree with others, that behaviour is intended. You can always use 
> single-clicks to scroll one line/page only. If you always get 
> double-clicks, then you may have to adjust your double-click time.
> 
The speed with which I click the button would absolutely be considered a 
double click by anyone's definition.  I simply have to learn to use 
things differently.

I still maintain though that there should be some way to quickly scroll 
in small increments using the mouse without unintended behavior.  I'd 
prefer 2 separate directional arrow buttons that have the differing 
behaviors.  And the double click should never scroll to top/bottom in 
the empty area where the slider is not IMHO.  That should always be a 1 
page only scroll.

The double click functionality could also be made configurable, maybe 
even just as a build time thing so as to not reduce performance.

It's funny I've always just dragged the slider to the bottom to scroll 
to top or bottom.  I've never found that to be a big problem or 
excessively difficult.  Clearly I am an outlier here though!

Thanks,
Mark

Re: [Freemint-discuss] XaAES Scroll Click Behavior

[Mark D. <mdu...@at...>]

On 12/23/23 8:31 AM, ps...@sc... wrote:
> I actually the double click on the arrow that scrolls to the end.  I 
> wish windoze did it.
> 
> Maybe change your double click delay time ?
> 
> Merry Christmas,
> 
> Peter

All I really needed is one person to say they like the behavior to 
realize I need to find another way ;)  Indeed I can see how instant 
scroll to bottom would be useful.

Mark

Re: [Freemint-discuss] XaAES Scroll Click Behavior

[Mark D. <mdu...@at...>]

On 12/23/23 3:44 AM, Miro Kropáček wrote:
> On Sat, 23 Dec 2023 at 04:42, Mark Duckworth via Freemint-discuss 
> <fre...@li... 
> <mailto:fre...@li...>> wrote:
> 
>     If you double click in the empty area OR the arrow it scrolls to the
>     maximum extent.  It makes it impossible to simply scroll a few times
>     quickly.
> 
> Does it happen also with the old XaAES: 
> https://github.com/freemint/freemint/files/10470058/xaaes-ozk-20220626-repacked.zip <https://github.com/freemint/freemint/files/10470058/xaaes-ozk-20220626-repacked.zip> ?
> 

Yes it still does.  I mean it's a feature that I can see in the code, 
and has been there for a very very long time based on the github blame.

Probably I should think about the problem more closely.  I have large 
scrollbuffers in toswin2 which makes the scroller very small.  Small 
slides result in huge multipage changes.  So I tend to try to click the 
up and down arrow which doesn't even exist on other platforms.

Really the issue that I should fix is to make the toswin2 scrollbuffer 
not use the full buffer size (and slider increment) until there is 
actually contents there.

Additionally toswin2 has another issue where the screen won't update 
while holding a key.  I'm sure this is some type of efficiency thing but 
it doesn't exactly help for scrolling through a file in a text editor.

I also should probably try to use the keyboard shortcuts and mouse wheel 
for scrollback.

Even so, TOS doesn't do the double click arrow scroll to top behavior. 
Personally I'd rather there be a separate button for it, or perhaps 
holding control or alt while clicking to enable or avoid such behavior.

Thanks,
Mark

Re: [Freemint-discuss] XaAES Scroll Click Behavior

[Thorsten O. <ad...@th...>]

On Samstag, 23. Dezember 2023 04:41:54 CET Mark Duckworth via Freemint-discuss 
wrote:
> If you double click in the empty area OR the arrow it scrolls to the
> maximum extent.

I agree with others, that behaviour is intended. You can always use single-
clicks to scroll one line/page only. If you always get double-clicks, then you 
may have to adjust your double-click time.

Re: [Freemint-discuss] XaAES Scroll Click Behavior

[<ps...@sc...>]

I actually the double click on the arrow that scrolls to the end.  I wish windoze did it.

Maybe change your double click delay time ?

Merry Christmas,

⁣Peter​

On 23 Dec 2023, 03:41, at 03:41, Mark Duckworth via Freemint-discuss <fre...@li...> wrote:
>Hello all,
>
>I was wondering if anyone else is as deeply offended as I am by the 
>XaAES behavior on the scrollbars specifically when you double click? 
>If you double click in the empty area OR the arrow it scrolls to the 
>maximum extent.  It makes it impossible to simply scroll a few times 
>quickly.
>
>Thanks,
>Mark
>
>
>_______________________________________________
>Freemint-discuss mailing list
>Fre...@li...
>https://lists.sourceforge.net/lists/listinfo/freemint-discuss

Re: [Freemint-discuss] XaAES Scroll Click Behavior

[Joakim H. <go...@gm...>]

On 23/12/2023, Mark Duckworth via Freemint-discuss
<fre...@li...> wrote:
> Hello all,
>
> I was wondering if anyone else is as deeply offended as I am by the
> XaAES behavior on the scrollbars specifically when you double click?
> If you double click in the empty area OR the arrow it scrolls to the
> maximum extent.  It makes it impossible to simply scroll a few times
> quickly.

At least double clicking on the arrow widget is supposed to move the
scroller to the end position AFAIK. Right double clicking is inverting
the direction. I think N.AES does the same?

Personally I see it as an absolute must have, makes navigating a
window way much smoother and faster.

Re: [Freemint-discuss] XaAES Scroll Click Behavior

[Miro K. <mir...@gm...>]

On Sat, 23 Dec 2023 at 04:42, Mark Duckworth via Freemint-discuss <
fre...@li...> wrote:

> If you double click in the empty area OR the arrow it scrolls to the
> maximum extent.  It makes it impossible to simply scroll a few times
> quickly.
>
Does it happen also with the old XaAES:
https://github.com/freemint/freemint/files/10470058/xaaes-ozk-20220626-repacked.zip
?

-- 
http://mikro.atari.org

[Freemint-discuss] XaAES Scroll Click Behavior

[Mark D. <mdu...@at...>]

Hello all,

I was wondering if anyone else is as deeply offended as I am by the 
XaAES behavior on the scrollbars specifically when you double click? 
If you double click in the empty area OR the arrow it scrolls to the 
maximum extent.  It makes it impossible to simply scroll a few times 
quickly.

Thanks,
Mark

[Freemint-discuss] Vampire V2 Ethernet Driver

[Mark D. <mdu...@at...>]

Hello all,

This is my first attempt at a kernel contribution so be gentle (but 
thorough) ;)

https://github.com/freemint/freemint/pull/326

This is a driver for the Vampire V2 Expansion Port ethernet known under 
Amiga OS as V2ExpEth.  The actual ethernet adapter is a ~$3 SPI ENC28J60 
adapter.  It is still a work in progress but it seems stable enough to 
share.  I am still gradually finding bugs and places to tighten up timing.

Mark

Re: [Freemint-discuss] SpareMiNT top crashes on recent kernels

[Miro K. <mir...@gm...>]

On Fri, 8 Dec 2023 at 21:42, Jo Even Skarstein <jo...@on...> wrote:

> The most recent kernel I've used where this works is built June 14th
> 2020. Tested on my Milan060 and Falcon CT60/SV with various kernels.

As it's crashing for me, too (latest snapshot, just had to wait a few
seconds), it was quite easy to biset. The regression was introduced two
weeks later. I've created an issue for it:
https://github.com/freemint/freemint/issues/325.

-- 
http://mikro.atari.org

Re: [Freemint-discuss] SpareMiNT top crashes on recent kernels

[Mark D. <mdu...@at...>]

On 12/8/23 3:41 PM, Jo Even Skarstein wrote:
> The old SpareMiNT top crashes with a bus error on recent kernels.
> 
> https://freemint.github.io/sparemint/sparemint/html/packages/pstop.html
> 
> The most recent kernel I've used where this works is built June 14th
> 2020. Tested on my Milan060 and Falcon CT60/SV with various kernels.
> 
> Jo Even

If it helps I did port procps-ng.  It seems my 68k build is older than 
my coldfire one but I installed it under aranym and seems to work.  I'd 
backup your current procps if that's where sparemnnt top originally 
comes from (I forget actually).

https://storage.atari-source.org/atari/personal/package_staging/procps-ng-3.3.0-1.m68kmint.rpm

Mark

Re: [Freemint-discuss] SpareMiNT top crashes on recent kernels

[Thorsten O. <ad...@th...>]

On Freitag, 8. Dezember 2023 21:41:42 CET Jo Even Skarstein wrote:
> The old SpareMiNT top crashes with a bus error on recent kernels.
> 
> https://freemint.github.io/sparemint/sparemint/html/packages/pstop.html
> 
> The most recent kernel I've used where this works is built June 14th
> 2020. Tested on my Milan060 and Falcon CT60/SV with various kernels.
> 
> Jo Even

I still have the same version here. It looks a bit strange, but doesn't crash:

[Freemint-discuss] SpareMiNT top crashes on recent kernels

[Jo E. S. <jo...@on...>]

The old SpareMiNT top crashes with a bus error on recent kernels.

https://freemint.github.io/sparemint/sparemint/html/packages/pstop.html

The most recent kernel I've used where this works is built June 14th
2020. Tested on my Milan060 and Falcon CT60/SV with various kernels.

Jo Even

Re: [Freemint-discuss] Kernel driver preemption

[Thorsten O. <ad...@th...>]

On Dienstag, 5. Dezember 2023 18:36:32 CET Mark Duckworth via Freemint-discuss 
wrote:
> Unless the kernel simply doesn't preempt itself.

I currently can't find the location, but no preempt takes place when you were 
previously in supervisor mode (which will be the case if you are in the 
kernel).  This is what causes the trouble with GEM=ROM, because original 
desktop runs in supervisor all the time.

Re: [Freemint-discuss] Kernel driver preemption

[Miro K. <mir...@gm...>]

On Tue, 5 Dec 2023 at 18:37, Mark Duckworth via Freemint-discuss <
fre...@li...> wrote:

> my worry is that a send is preempted by the 200hz timer to receive
>
1. Take a look at how other drivers are implemented
2. Get something working
3. Worry later :)

As the expression goes, perfect is the enemy of the good. :)

-- 
http://mikro.atari.org