You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
and I call tmemClose() before calling framebufferClose()
You are not supposed to do that. Remove tmemClose() call. nvExit gets stuck because passed TransferMemory is not RW anymore and it expects it to be RW before closing it on its own and returning.
tmemWaitForPermission() is there because passing ownership of Transfermem is async. So in default conditions you cannot be 100% sure it is immediately available after closing service (there were already confirmed cases of race condition). If it can't detect that passed Transfermem is RW, it waits infinitely.
I'm sorry but I removed the call to tmemClose() and the call to framebufferClose() still blocks at the same place. I am using the 4.10.0-1 version of libnx.
Well I fixed this issue by not allocating the Transfer memory by myself and setting u32 __nx_nv_transfermem_size = 0x15000;.
But now I have different problem... The second time I call framebufferCreate() after the call to framebufferClose(), the result is R_MODULE=345, R_DESCRIPTION=2
Let me give you more context: I am developing a sysmodule that shows popups and it supposed to work with Tesla overlay for control. But the problem is that both sysmodules can't use VI at the same time. When I don't close the framebuffer and VI Tesla don't show up anymore. That's the reason why I need to close the framebuffer and VI to let Tesla work, and later take it back, and so on.
Activity
TristanIsrael commentedon Dec 19, 2025
I precise I use TransferMemory (
tmemCreateFromMemory()) and I calltmemClose()before callingframebufferClose()masagrator commentedon Dec 19, 2025
You are not supposed to do that. Remove tmemClose() call. nvExit gets stuck because passed TransferMemory is not RW anymore and it expects it to be RW before closing it on its own and returning.
tmemWaitForPermission()is there because passing ownership of Transfermem is async. So in default conditions you cannot be 100% sure it is immediately available after closing service (there were already confirmed cases of race condition). If it can't detect that passed Transfermem is RW, it waits infinitely.TristanIsrael commentedon Dec 19, 2025
Great thank you. I'll fix that.
TristanIsrael commentedon Dec 19, 2025
I'm sorry but I removed the call to
tmemClose()and the call toframebufferClose()still blocks at the same place. I am using the 4.10.0-1 version of libnx.TristanIsrael commentedon Dec 19, 2025
An additional information, I declared this function
and in my log I can see that
Permission == 0, which meansPerm_None, maybe that is a problem?TristanIsrael commentedon Dec 19, 2025
Well I fixed this issue by not allocating the Transfer memory by myself and setting
u32 __nx_nv_transfermem_size = 0x15000;.But now I have different problem... The second time I call
framebufferCreate()after the call toframebufferClose(), the result isR_MODULE=345, R_DESCRIPTION=2Let me give you more context: I am developing a sysmodule that shows popups and it supposed to work with Tesla overlay for control. But the problem is that both sysmodules can't use VI at the same time. When I don't close the framebuffer and VI Tesla don't show up anymore. That's the reason why I need to close the framebuffer and VI to let Tesla work, and later take it back, and so on.