Hacking Unofficial Luma build discussion

[Nutez]

Hi folks, here's the tl;dr:
I will update the fork to 11.0, with at least the "auto CTRNAND boot.firm write" feature disabled (for fastboot3DS users such as myself). However, I'm not looking to rush this out since it's a major version number change (i.e. "breaking changes") and there seems to be a BootNTRSelector compatibility issue. I may do a pre-release for testing.

Anyways, thanks to the Luma team for their update as I know it will help a lot of casual users. And hopefully other folks are willing to workaround, fork or wait a little longer .

 

[BETA215]

I can't think of a scenario where this would happen to someone who doesn't know what they're doing. Everyone with a "standard" guide-based setup won't ever have anything other than Luma as boot.firm (except maybe SafeB9SInstaller if updating B9S, which doesn't chainload anywhere anyway). If you are in a scenario where you're booting Luma from SD from a location other than as boot.firm, you're probably more likely to not have boot.firm in the first place, but more importantly you would be able to recognize if something is going weird (not to mention booting without SD with fastboot3DS would bring up its configuration IIRC rather than power off (now with notification LED colour) like B9S does).


SD writes aren't really relevant here. Luma is already known to sometimes have conflicting config if you're switching between old and new versions (maybe even forks if they have different config?), which has nothing to do with the CTRNAND copy feature. The CTRNAND writes are IMO negligible compared to both what the 3DS writes and to what a power user would be writing.

As far as I can tell, Luma will only attempt to write itself once per version (not entirely sure in what way forks are implicated this, but it seems to be implied here that if you run base Luma first then forks will not attempt to write boot.firm to CTRNAND).

---

The feature is ultimately to ensure that each and every person is able to boot on CTRNAND. If you're a casual fork user, you probably don't care what CTRNAND boot.firm is - the critical factor is whether your 3DS can boot if your SD failed for some reason, and whether you use a fork or not doesn't really matter in that case.

I don't personally take issue with a fork like this one removing this feature because 99% of the time the people that the feature targets (people that don't really know what they're doing) will only ever run and use base Luma (or maybe 3GX Luma, but either way they'd have a working Luma as boot.firm on CTRNAND). But the portrayal of the feature as generally anti-user bugs me a bit. An inconvenience to very specific types of power users, maybe (if the forks end up fighting each other to make themselves CTRNAND boot.firm).

In my opinion, if more work towards making Luma3DS noob-proof starts happening, maybe making an official Luma3DS version for the guide/NH would be cool, and keeping a separate one without those changes that take power away from the user (in lots of cases, for a pretty good reason).

Thankfully there are wonderful forks like this one that can help us in small changes like the current one, but it feels scary to me if we're gonna start losing the possibility to choose what we can do (since there's no alternative to Luma3DS yet, relying on fork's devs).

 

[dustinbv]

Hi, I really like your Luma build!! For the last hour I've been trying to set it up thy way I want it to be.
My n3DS XL has a top IPS screen that is more dim than the bottom screen and has a blue tint.
Is there any way to get the top screen permanently brighter than the bottom screen together with a less-blue screen filter?
I can get them both looking the same, but only until reboot. Any help is appreciated

 

[Nutez]

Hi, I really like your Luma build!! For the last hour I've been trying to set it up thy way I want it to be.
My n3DS XL has a top IPS screen that is more dim than the bottom screen and has a blue tint.
Is there any way to get the top screen permanently brighter than the bottom screen together with a less-blue screen filter?
I can get them both looking the same, but only until reboot. Any help is appreciated

Thanks, glad you like it. Unfortunately, there isn't a simple solution that I could implement myself for that. Both screens read their brightness from the same value in config and my attempts to set them independently during the boot process just glitched them out dangerously...
I have heard that it is possible to edit the "brightness curve" used by each screen independently, however, it requires some math and dev skills that are beyond my script-kiddie level XD.

 

[dustinbv]

Bummer; but nonetheless still I am very glad to be able to do it manually. And it just takes a few seconds of button pressing to finally have matching screens.
I would have liked to contribute to the brightness-curve-thing, but my math and dev skills are practically nonexistent haha
Really, I am so thankful for what you have done with this build. Otherwise my experience would be much worse.

 

[T0biasCZe]

how to make the revert widescreen option work? i have patched widescreen through twpatcher, and the ds games boot in widescreen, but the option in the rosalina menu says "unneeded"

 

[Pk11]

how to make the revert widescreen option work? i have patched widescreen through twpatcher, and the ds games boot in widescreen, but the option in the rosalina menu says "unneeded"

It says it "isn't needed in most cases", not "unneeded". This is one of the cases where it is needed.

To get automatically enabling/disabling to work, follow the official guide. Specifically step 10 is what you may have missed.

Edit: Just realized this was the unofficial luma thread not the TWiLight thread lol, apologies if what I said isn't correct for quick switcher luma, it's probably still correct though.

 

[T0biasCZe]

It says it "isn't needed in most cases", not "unneeded".

no

 

[Nutez]

no

You've created a single TwlBg.cxi with Widescreen enabled, but not renamed it so it is being used by default in TWL mode. You can either delete the TwlBg.cxi from your SD "/luma/sysmodules/" to remove the Widescreen entirely, or do the setup to use the Quick-Switchers outlined below.

To use Widescreen via TWiLight Menu, you would need to follow the guide mentioned above.

If you want to change between different filters while using Widescreen via TWiLight Menu then create and rename the TwlBg.cxi files (e.g. wideWithRedshift.cxi, wideSharpFIlter.cxi etc.) and place them in "/luma/sysmodules/Widescreen". The folder needs to contain at least 2 renamed .cxi files.

If you want to switch without TWiLight Menu; create and rename the TwlBg.cxi files (e.g. wideWithRedshift.cxi, wideSharpFIlter.cxi etc.) and place them in "/luma/sysmodules/TwlBg". The folder needs to contain at least 2 renamed .cxi files.

Hope that helps .

 

[jDSX]

I have a question, would I be able to switch from luma 11.0 to 10.3 custom/unofficial build? Would there be any problems with my current games if I were to do that gameplay wise?

My O3DSXL is japanese model if it matters.

 

[Nutez]

Sorry folks, I've not had the time to do the update properly, so it's just a hacky prerelease for now. Here you can see that the config MCU write, the boot.firm NAND write and old config.bin deletion has been disabled by commenting it all out. Downside is that I have also had to temporarily disable the new screen filter reapply feature because it clashes with Night/Light (though Night/Light does the same thing and more).

I have a question, would I be able to switch from luma 11.0 to 10.3 custom/unofficial build? Would there be any problems with my current games if I were to do that gameplay wise?

My O3DSXL is japanese model if it matters.

There should be no issues with doing that. However, you could also try this prerelease attached now instead.

 

[Yrouel]

Sorry folks, I've not had the time to do the update properly, so it's just a hacky prerelease for now. Here you can see that the config MCU write, the boot.firm NAND write and old config.bin deletion has been disabled by commenting it all out. Downside is that I have also had to temporarily disable the new screen filter reapply feature because it clashes with Night/Light (though Night/Light does the same thing and more).


There should be no issues with doing that. However, you could also try this prerelease attached now instead.

I think that's too far. The only thing to comment out to disable the automatic write to nand of boot.firm is this

// Try to boot.firm to CTRNAND, when applicable
if (isSdMode)
    ok = fileCopy("0:/boot.firm", "1:/boot.firm", true, fileCopyBuffer, sizeof(fileCopyBuffer));

inside fs.c (https://github.com/DullPointer/Luma...dbe5630d8f50fabef8471d9f0382/arm9/source/fs.c).

Everything else (the new config system etc) is fine

 

[Nutez]

I think that's too far. The only thing to comment out to disable the automatic write to nand of boot.firm is this

// Try to boot.firm to CTRNAND, when applicable
if (isSdMode)
    ok = fileCopy("0:/boot.firm", "1:/boot.firm", true, fileCopyBuffer, sizeof(fileCopyBuffer));

inside fs.c (https://github.com/DullPointer/Luma...dbe5630d8f50fabef8471d9f0382/arm9/source/fs.c).

Everything else (the new config system etc) is fine

It does use the new config.ini system. It just doesn't save the version details to the MCU, because that data is just used to determine whether to do the boot.firm copy to NAND.

 

[Deleted member 530846]

Are you working on the update to Luma v11??

 

[The Catboy]

Are you working on the update to Luma v11??

I was just about to ask about this.
Been following this thread eagerly awaiting an update

 

[Deleted member 530846]

Are you working on the update to Luma v11??

He's working at the update, he just tell me at dm

 

[Izooc]

Has anyone had the screen fry from the max hidden brightness?

 

[al_kaloid]

Hi guys,

thank you for this unofficial build of an already fantastic piece of work Nutez!
Ever since I found out the displays Nintendo didn't give a damn about could be calibrated/adjusted I fell in love with my 3DS's all over again. Love the QoL features, too.

I have a pretty severe issue using this build (that seems related to what Izooc was asking I guess), I hope it fits in here and you'll excuse the wall of text, otherwise just go for the TL;DR:

Used Nutez' Luma 10.2.x version ever since I found out about it and recently tried your v11 prerelease to be able to upgrade to the new Nintendo system update. The problem described below persists until I use the official Luma 11 version (without the much needed filter options). I don't know when it started exactly.
I also recently migrated from a 64GB to a 128GB mSD card by means of simple copypasta. Maybe some value is applied twice because of this or it's relevant? But let me start at the beginning.

I recently noticed that my N3DS XL top screen (top IPS, bottom TN, don't think this matters) started to flicker after booting into the 3DS home menu and stopped doing so gradually after about half a minute or so. Most noticeable in the top right corner.

I checked my Rosalina menu custom filter settings (Night/Light modes are awesome) and everything looked fine to me, checked the "Change screen brightness" option and got shocked. The top screen luminance was at an alarming 285!
Around double the regular value (seems oddly specific?). I was basically frying my beloved IPS top screen for the last weeks or so at least (ever since the flickering started, maybe even earlier without symptoms).

If the settings got mangled somehow and I'd be able to resolve this I probably wouldn't post, but here is what is strange:

The permanent brightness recalibration menu shows the regular luminance values: Level 1-5: 16, 28, 48, 82, 142.
If I change these a bit and save or just save the values as is and reboot the system or close the shell, it's back at 285, 164 or the corresponding value for the set system brightness.
I've only tried this a few times due to the mention of NAND wear and don't know what else to try or why my changes are being ignored (and/or applied twice?!) and why only for the top screen.

Trying to change the brightness manually in screen brightness menu works okay but is only temporary ofc (as it's stated).

TL;DR: Top screen brightness/luminance always reverts back to double the preset value (285 (!) instead of 142 etc.) after reboot, no matter how often I try to edit and save my settings in Rosalina menu. Really bad for my screen, only fix so far is to not use the unofficial Luma build by Nutez. I'd like to know why and how to properly fix it because I really love the custom screen filter options. I'll happily provide additional info.

Huge thanks in advance and sorry for this midnight novel -_-'
al

 

[Sono]

Has anyone had the screen fry from the max hidden brightness?

Should not fry the display itself if you have a TN display, but it should eventually fry the backlight though (don't know if there is any current limit besides the short-circuit detector), so don't run the display above ~412 for an extended time.

Hi guys,

thank you for this unofficial build of an already fantastic piece of work Nutez!
Ever since I found out the displays Nintendo didn't give a damn about could be calibrated/adjusted I fell in love with my 3DS's all over again. Love the QoL features, too.

I have a pretty severe issue using this build (that seems related to what Izooc was asking I guess), I hope it fits in here and you'll excuse the wall of text, otherwise just go for the TL;DR:

Used Nutez' Luma 10.2.x version ever since I found out about it and recently tried your v11 prerelease to be able to upgrade to the new Nintendo system update. The problem described below persists until I use the official Luma 11 version (without the much needed filter options). I don't know when it started exactly.
I also recently migrated from a 64GB to a 128GB mSD card by means of simple copypasta. Maybe some value is applied twice because of this or it's relevant? But let me start at the beginning.

I recently noticed that my N3DS XL top screen (top IPS, bottom TN, don't think this matters) started to flicker after booting into the 3DS home menu and stopped doing so gradually after about half a minute or so. Most noticeable in the top right corner.

I checked my Rosalina menu custom filter settings (Night/Light modes are awesome) and everything looked fine to me, checked the "Change screen brightness" option and got shocked. The top screen luminance was at an alarming 285!
Around double the regular value (seems oddly specific?). I was basically frying my beloved IPS top screen for the last weeks or so at least (ever since the flickering started, maybe even earlier without symptoms).

If the settings got mangled somehow and I'd be able to resolve this I probably wouldn't post, but here is what is strange:

The permanent brightness recalibration menu shows the regular luminance values: Level 1-5: 16, 28, 48, 82, 142.
If I change these a bit and save or just save the values as is and reboot the system or close the shell, it's back at 285, 164 or the corresponding value for the set system brightness.
I've only tried this a few times due to the mention of NAND wear and don't know what else to try or why my changes are being ignored (and/or applied twice?!) and why only for the top screen.

Trying to change the brightness manually in screen brightness menu works okay but is only temporary ofc (as it's stated).

TL;DR: Top screen brightness/luminance always reverts back to double the preset value (285 (!) instead of 142 etc.) after reboot, no matter how often I try to edit and save my settings in Rosalina menu. Really bad for my screen, only fix so far is to not use the unofficial Luma build by Nutez. I'd like to know why and how to properly fix it because I really love the custom screen filter options. I'll happily provide additional info.

Huge thanks in advance and sorry for this midnight novel -_-'
al

Sounds like gsp gets stuck in 3D mode. In 3D mode the brightness is basically almost perfectly doubled (that's why you see the brightness "pop" when you switch between 3D and 2D mode), and it seems to be getting constantly applied for some reason. It can't really be anything else, especially if you can make it temporarily stick the good value that's clearly a new3DS gsp behavior with the brightness weirdness, and your symptoms match exactly.

tl;dr: something patches gsp in a way which makes it get stuck in 3D brightness without actually turning up on the 3D slider.

As for the display flickering, is it a replacement display, or Nintendo original?
If it's original, does the IPS display have some weird vignette pattern around the sides and edges? Especially the "shape" of the flicker you're seeing in the corner.

 

[ghjfdtg]

The flicker is caused by Luma's screen init in combination with a boot splashscreen. Known issue.