text:
Setting environment variable doesn't work to authenticate

I've run the command:
mongo-connector -m localhost:27017 -t http://localhost:7474/db/data -d neo4j_doc_manager
Here is the log:
No handlers could be found for logger "mongo_connector.util"
Traceback (most recent call last):
  File "/usr/local/bin/mongo-connector", line 9, in <module>
    load_entry_point('neo4j-doc-manager==1.0.0.dev11', 'console_scripts', 'mongo-connector')()
  File "/Library/Python/2.7/site-packages/mongo_connector/util.py", line 90, in wrapped
    func(*args, **kwargs)
  File "/Library/Python/2.7/site-packages/mongo_connector/connector.py", line 1059, in main
    conf.parse_args()
  File "/Library/Python/2.7/site-packages/mongo_connector/config.py", line 118, in parse_args
    option, dict((k, values.get(k)) for k in option.cli_names))
  File "/Library/Python/2.7/site-packages/mongo_connector/connector.py", line 854, in apply_doc_managers
    dm_instances.append(DocManager(target_url, **kwargs))
  File "/Library/Python/2.7/site-packages/mongo_connector/doc_managers/neo4j_doc_manager.py", line 38, in __init__
    self.graph = Graph(url)
  File "/Library/Python/2.7/site-packages/py2neo/database/__init__.py", line 327, in __new__
    use_bolt = version_tuple(inst.__remote__.get().content["neo4j_version"]) >= (3,)
  File "/Library/Python/2.7/site-packages/py2neo/database/http.py", line 157, in get
    raise Unauthorized(self.uri.string)
py2neo.database.status.Unauthorized: http://localhost:7474/db/data/

I've set the NEO4J_AUTH env variable. I can read it.
~> env | grep NEO4J
NEO4J_AUTH=neo4j:neo4j

I couldn't see py2neo's authenticate(url, usr, pass) method call in the source code. Or anything about NEO4J_AUTH variable. Is there something I've missed?

I just spend my afternoon on this problem too.
When I do a
curl --user neo4j:neo4j http://localhost:7474/data/db
It is working. But when It's not working with mongo connector.
Any update?

Dealt with the same issue. Had to put the following in the neo4j_doc_manager.py
https://github.com/neo4j-contrib/neo4j_doc_manager/blob/master/mongo_connector/doc_managers/neo4j_doc_manager.py#L40
auth = os.environ.get('NEO4J_AUTH')

if auth:
    auths = auth.split(':')
    authenticate(url.strip('http://'), auths[0], auths[1])

self.graph = Graph(url)

I tried the suggestion by @mishgunn but no luck for me... :-(

Has this problem been solved now? I had the same problem.

authors: AyWa HongwenHan mishgunn osrl trickidicki


text:
php ds dependency

Library version: 2.1.1
php-ds was removed as a dependency in 5e36e22c65157142dfc4d6f044fe374711167245, but I think it may still be required.
I have done a fresh composer update with the latest version (2.1.1) and I get this error:
PHP Fatal error:  Uncaught Error: Class "Ds\Map" not found in vendor/laudis/neo4j-php-client/src/ClientBuilder.php:67
Stack trace:
#0 file.php(1): Laudis\Neo4j\ClientBuilder::create()

You are absolutely correct, it appears my search and replace didn't work correctly. I'll fix it now!

Fixed in version 2.1.2 and commits #7eadbc18969efad47f246ed98ec235212f7031a2 and #db90921fc65ffaa550d7fbd26c37bb8a32bb98de

source: gharchive/issue

license: MIT

license_type: permissive

license_source: github-api


text:
Implement @Query in Spring Data Neo4J - Part 1

Part 1 of @Query implementation of Spring Data Neo4J talking with the new Neo4J OGM. Part 2 will focus on parameter binding and strengthening testcases.

Manally merged.

@vince-bickers Is there any reason my work wasn't merged? It seems to have been copied and pasted into master and all my commits have been clobbered which doesn't seem very fair. :(

@mangrish your pull request couldn't be automatically merged because of conflicting changes to master by the time I came to it. So I followed the instructions here to to do a console based merge. I have no idea why your commit comments were not included, but it wasn't deliberate.

source: gharchive/pull-request

authors: mangrish vince-bickers


text:
Who can tell me what's wrong?

Traceback (most recent call last):
  File "/data/django-uwsgi/text_labeled/create_graph/build.py", line 44, in <module>
    create_label_node_and_rel()
  File "/data/django-uwsgi/text_labeled/create_graph/build.py", line 13, in create_label_node_and_rel
    _driver = GraphDatabase.driver(**NEO4J_CONFIG)
  File "/root/anaconda3/lib/python3.6/site-packages/neo4j/__init__.py", line 181, in driver
    return cls.bolt_driver(parsed.netloc, auth=auth, **config)
  File "/root/anaconda3/lib/python3.6/site-packages/neo4j/__init__.py", line 194, in bolt_driver
    return BoltDriver.open(target, auth=auth, **config)
  File "/root/anaconda3/lib/python3.6/site-packages/neo4j/__init__.py", line 356, in open
    pool_config, default_workspace_config = Config.consume_chain(config, PoolConfig, WorkspaceConfig)
  File "/root/anaconda3/lib/python3.6/site-packages/neo4j/conf.py", line 111, in consume_chain
    raise ConfigurationError("Unexpected config keys: %s" % ", ".join(data.keys()))
neo4j.exceptions.ConfigurationError: Unexpected config keys: encrpted

Unexpected config keys: encrpted sais it all i think. You misspelled encrypted.

neo4j.exceptions.ConfigurationError: Unexpected config keys: encrpted
encrptd is misspelled, it should be encrypted
https://neo4j.com/docs/api/python-driver/4.0/api.html#encrypted

license_source: bigquery


text:
fix: decrease and insanely long timeout

Let us fix that insanity I created please.
do not wait 1200/600 minutes for VM
Signed-off-by: Tibor Dudlák tdudlak@redhat.com

LGTM

authors: Tiboris bhavikbhavsar

repo: neoave/mrack


text:
LLVM ERROR: Global variable 'security_txt' has an invalid section specifier '.security.txt'

After adding a security_txt! in my src/lib.rs, cargo build and cargo test begin to fail with this error:

LLVM ERROR: Global variable 'security_txt' has an invalid section specifier '.security.txt': mach-o section specifier requires a segment and section separated by a comma.

cargo +bpf build --target bpfel-unknown-unknown --release (which is being called by anchor build) does seem to work without issues even with the macro left in though
Copying the macro directly into the code and removing the #[link_section] line also works fine
#[macro_export]
macro_rules! security_txt {
    ($($name:ident: $value:expr),*) => {
        #[allow(dead_code)]
        #[no_mangle]
        // #[link_section = ".security.txt"] // removing this works
        pub static security_txt: &str = concat! {
            "=======BEGIN SECURITY.TXT V1=======\0",
             $(stringify!($name), "\0", $value, "\0",)*
            "=======END SECURITY.TXT V1=======\0"
        };
    };
}

What OS are you using? From mach-o in the error I am inferring macos?

Yup macos, here's this if it helps
$ sw_vers
ProductName:	macOS
ProductVersion:	12.3.1
BuildVersion:	21E258
$ uname -mrs
Darwin 21.4.0 x86_64

Yeah there seems to be an issue with the section name if building natively for mac, as you would for tests.
We didn't test with mac's beforehand. I'll think about how to best fix it. Might just drop the section thing all-together. It's kinda nice to have, but not when it breaks things. Or we could only include it when the target is eBPF.
Thanks for the report!

No problem, thanks for the quick response!
If I'm reading the code comments correctly, it's fine to just comment out the #[link_section] since it's optional in the standard anyway? Would prefer doing that rather than manually removing/adding the whole security_txt back in when I build natively vs for release

Yes, feel free to remove it.

Fixed in b08a4316cca2f86f977cb0b13fc57bdc93406227

authors: CherryWorm jonorally tlambertz

repo: neodyme-labs/solana-security-txt


text:
Threadsafe Handles

Two new Send + Sync features are introduced: EventQueue and Persistent. These features work together to allow multi-threaded modules to interact with the Javascript main thread.

EventQueue: Threadsafe handle that allows sending closures to be executed on the main thread.
Persistent<T>: Opaque handle that can be sent across threads, but only dereferenced on the main thread.

Finished my review! This is going to be a great addition to the core primitives of Neon. I'm psyched.

@dherman This is close to stabilization. One change I would like to make prior to merging is the addition of a return value. Two APIs to take inspiration from:

std::thread::spawn
tokio::spawn

In both of these APIs, a JoinHandle is returned. On a thread::spawn, a user can call join to block until the thread exits and get the return value. Similarly, in tokio, the handle can be awaited to get the resolved value.
I propose the following changes:
struct Channel
    pub fn send<T, F>(&self, f: F) -> JoinHandle<T>
    where
        T: Send + 'static,
        F: FnOnce(TaskContext) -> NeonResult<T>;

We don't need to initially do anything with the returned JoinHandle, but by adding it there, it allows extension without breaking changes to introduce JoinHandle::join and impl Future for JoinHandle.
Also, I'm still not feeling certain send is the right choice. Maybe it should be renamed spawn? If it is renamed spawn, Channel probably isn't the best name either.

This is a great idea @kjvalencik.
I think I do like send better than spawn, though, because we aren't spawning a thread (not even conceptually like a green thread), the user should be thinking of it as sending information back to an existing thread. As far as mixing traditions (channel / join) I think I'm comfortable with it: conceptually we're dealing with a channel because we're communicating between threads, and conceptually we're dealing with joining because we're blocking on another thread's computation.

Merged in https://github.com/neon-bindings/rfcs/commit/c6396817a56f323ae1d452d373c22513f6d7425b

authors: dherman kjvalencik

repo: neon-bindings/rfcs


text:
Store page image for HEAP2_PRUNE with FPI

I noticed that massive update (i.e. "update t set x=x+1") cause generation of a lot of HEAP2_PRUNE war records with FPI.
And looking at code of heap_xlog_prune I noticed that it it does nothing except extracting image when contains FPI.
Well, not exactly true - it also updates FSM. But we in any case ignore this updates.
So HEAP2_PRUNE+FPI can be handled by pageserver itself (as it is done for XLOG_FPI) by storing page image than applying WAL record.

is there ever a reason to avoid storing an image every time we see apply_image?
I can see that storing a log record would allow extra checks to be performed while replaying a log record chain, but I wonder if we can introduce a middle ground: log based page images. They would not require base page for replay (as they initialize the page) but would be more compact than a database page (and carry extra debug info)

is there ever a reason to avoid storing an image every time we see apply_image?
I can see that storing a log record would allow extra checks to be performed while replaying a log record chain, but I wonder if we can introduce a middle ground: log based page images. They would not require base page for replay (as they initialize the page) but would be more compact than a database page (and carry extra debug info)

I am not sure that other records with FPI doesn't perform some other actions except just restoring page image.
I will check it.

I wonder what the performance impact of this really is though

I make this change because I have noticed that after huge update, WAL mostly consists of HEAP PRUNE. What is the impact?
pgbench -h 127.0.0.1 -p 55432 -i -s 100 -U zenith_admin postgres
update pgbench_accounts set abalance=abalance+1;
select sum(abalance) from pgbench_accounts;

Version
Update time
Select time

main
565108
333328

patch
512341
126380

So it is more than two times.
And just few lines of code.
Frankly speaking I do not understand why we should "drop this for now"...

Oh, ok, I didn't expect such a big difference. Let's get it in then

And can you also add that test case to our performance test suite, please? Unless that difference can already be seen by some of our existing tests.

I have added test. Results with this tests are not so impressive as with pgbench (do not know why), but still there is difference:
main:
test_update[vanilla].update: 111.283 s
test_update[vanilla].select: 15.674 s
test_update[zenith].update: 151.852 s
test_update[zenith].select: 106.677 s

prune_fpi:
test_update[vanilla].update: 117.247 s
test_update[vanilla].select: 13.419 s
test_update[zenith].update: 149.896 s
test_update[zenith].select: 85.538 s

But the positive result is visible only on 10M rows.
In this case execution of this test takes significant amount of time and is canceled by CI timeout.
Show I parameterize number of rows and make it smaller for CI?

Sorry, looks like effect is also visible at smaller number of rows:
main:
test_update[vanilla-1000000].update: 13.308 s
test_update[vanilla-1000000].select: 1.067 s
test_update[zenith-1000000].update: 8.605 s
test_update[zenith-1000000].select: 3.111 s

prune_fpi:
test_update[vanilla-1000000].update: 7.265 s
test_update[vanilla-1000000].select: 0.398 s
test_update[zenith-1000000].update: 8.744 s
test_update[zenith-1000000].select: 2.679 s

authors: antons-antons hlinnaka knizhnik

repo: neondatabase/neon


text:
Fix test_prepare_snapshot.

It should checkpoint pageserver after waiting for all data arrival, not before.
reported by
https://github.com/neondatabase/neon/actions/runs/3346541946/jobs/5543616053

Thanks @arssher

authors: arssher bayandin


text:
Local docker build instructions

People suggested various ways to docker build locally. I chose the one method that requires no AWS permissions or special tools to be installed, and allows local edits of the base rust image.

Unassigning myself. Someone take over if this is still a good idea to do


text:
update zerocopy

Problem
https://github.com/neondatabase/neon/security/dependabot/48
$ cargo tree -i zerocopy
zerocopy v0.7.3
└── ahash v0.8.5
    └── hashbrown v0.13.2

ahash doesn't use the affected APIs we we are not vulnerable but best to update to silence the alert anyway
Summary of changes
$ cargo update -p zerocopy --precise 0.7.31
    Updating crates.io index
    Updating syn v2.0.28 -> v2.0.32
    Updating zerocopy v0.7.3 -> v0.7.31
    Updating zerocopy-derive v0.7.3 -> v0.7.31

Checklist before requesting a review

[x] I have performed a self-review of my code.
[ ] If it is a core feature, I have added thorough tests.
[ ] Do we need to implement analytics? if so did you add the relevant metrics to the dashboard?
[ ] If this PR requires public announcement, mark it with /release-notes label and add several sentences in this section.

Checklist before merging

[ ] Do not forget to reformat commit message to not include the above checklist

Something went wrong with CI, so I'm going to rebase the PR to retrigger the build again

authors: bayandin conradludgate


text:
Use neon-github-ci-tests S3 bucket for remote_storage tests

This bucket is already used by the pytests. The current bucket github-public-dev is more meant for longer living artifacts.
slack thread: https://neondb.slack.com/archives/C039YKBRZB4/p1703124944669009
Part of https://github.com/neondatabase/cloud/issues/8233 / #6155

CI is broken for an unrelated reason and will be fixed in https://github.com/neondatabase/neon/pull/6217

authors: arpad-m bayandin


text:
pageserver: implement aligned io buffer

Problem
Summary of changes
Checklist before requesting a review

[ ] I have performed a self-review of my code.
[ ] If it is a core feature, I have added thorough tests.
[ ] Do we need to implement analytics? if so did you add the relevant metrics to the dashboard?
[ ] If this PR requires public announcement, mark it with /release-notes label and add several sentences in this section.

Checklist before merging

[ ] Do not forget to reformat commit message to not include the above checklist

Implemented in https://github.com/neondatabase/neon/pull/9326


text:
github archive change in table names

https://medium.com/@hoffa/github-archive-fully-updated-notice-some-breaking-changes-64e7e7cd0967
(I noticed the project is querying "githubarchive:day.events_", change to "githubarchive:day.")

Thanks for the heads-up — seems like there are more changes required to make this actually work again, though => have to do it some day :)

authors: fhoffa neonichu

repo: neonichu/githop

license: mit


text:
Can't get rust-analyzer working

nvim --version: NVIM v0.5.0
nvim-lspconfig version(commit hash):
What language server (If the problem is related to a specific language server): rust-analyzer
Can you reproduce this behavior on other language server clients (vscode, languageclient-neovim, coc.nvim, etc.): No
Can you reproduce this behavior on other language servers offered in the nvim-lspconfig repo? (pyls -> pyright): No
Is the problem isolated to a particular language server: rust-analyzer
Operating system/version: macOS 11.5.2

How to reproduce the problem from neovim startup

Put require'lspconfig'.rust_analyzer.setup{} in your init.lua.
Follow instructions here https://rust-analyzer.github.io/manual.html#rust-analyzer-language-server-binary
Open any rust project in nvim.
You'll see the error cmd ["rust-analyzer"] is not executable. upon opening your first rust file.
Try running chmod a+x /PATH/TO/rust-analyzer
Re-open any rust project in nvim
Open a rust file and see the error:

Error detected while processing FileType Autocommands for "rust":
E5108: Error executing lua ...llar/neovim/0.5.0/share/nvim/runtime/lua/vim/lsp/rpc.lua:384: start `rust-analyzer` faile
d: Unknown system error -86: Unknown system error -86

Actual behaviour
I see an error.
Expected behaviour
The rust lsp doesn't throw an error and works :)
Minimal init.vim or init.lua and code sample
Simply install nvim-lspconfig and put require'lspconfig'.rust_analyzer.setup{} in your ~/.config/nvim/init.lua.
Health check

Checkhealth result
health#lspconfig#check
Checking language server protocol configuration

INFO: dockerls: configuration checked.
ERROR: gopls: The given command "gopls" is not executable.
INFO: graphql: configuration checked.
INFO: rust_analyzer: configuration checked.
INFO: tsserver: configuration checked.
INFO: vimls: configuration checked.
INFO: bashls: configuration checked.

LSP log
It is unfortunately empty even with debug turned on.

Usage questions should be posted on our discourse.
I cannot reproduce your issue in a container, so it must be something with your system configuration/setup. Here is a container you can diff against your system/neovim configuration.
https://github.com/mjlbach/lsp-containers/tree/master/rust-analyzer

This issue has been mentioned on Neovim Discourse. There might be relevant details there:
https://neovim.discourse.group/t/cant-get-rust-analyzer-with-lsp-config/1028/1

I figured it out. I'd installed the wrong Apple version. I grabbed the M1 and not the Intel. 🤦♂

authors: jsatk mjlbach neovim-discourse

repo: neovim/nvim-lspconfig


text:
Merge #250

Merge #250 with small addition
Fix #250

Coverage increased (+0.003%) to 96.782% when pulling 429d6bd8f270fc9d13db48e6b659ba3a6b08ba69 on feature/merge_250 into fb89f3b2393febb784b3c63dd730af302f60a86c on develop.

[Current coverage][cc-pull] is 92.99%

Merging [#252][cc-pull] into [develop][cc-base-branch] will increase coverage by +<.01%

@@            develop       #252   diff @@
==========================================
  Files            19         19
  Lines          1211       1212     +1
  Methods           0          0
  Messages          0          0
  Branches        146        146
==========================================
+ Hits           1126       1127     +1
  Misses           39         39
  Partials         46         46

Powered by Codecov. Last updated by [fb89f3b...429d6bd][cc-compare]
[cc-base-branch]: https://codecov.io/gh/nephila/djangocms-blog/branch/develop?src=pr
[cc-compare]: https://codecov.io/gh/nephila/djangocms-blog/compare/fb89f3b2393febb784b3c63dd730af302f60a86c...429d6bd8f270fc9d13db48e6b659ba3a6b08ba69
[cc-pull]: https://codecov.io/gh/nephila/djangocms-blog/pull/252?src=pr

authors: codecov-io coveralls yakky

repo: nephila/djangocms-blog


text:
add example nb for hf transformers integration

Description
Add example notebook for HuggingFace Transformers Integration
❔ This change

[x] adds a new feature
[ ] fixes breaking code
[ ] is cosmetic (refactoring/reformatting)

✔ Pre-merge checklist
Mark which items have been completed:

[x] Refactored code (sourcery)
[x] Tested code locally
[ ] Added code to GitHub tests (notebooks, scripts)
[ ] Updated GitHub README

🪝 Run the following to both pre-commit hooks and JupyterLab (turn on format on save)

[x] Stripped outputs from notebooks - (nbstripout)
[x] Sorted imports - (isort)
[x] Formatted code - (back)

📄 Update documentation
Coordinate with @normandy7

[ ] Updated content in the docs
[ ] Added to all relevant docs index pages (e.g., Examples, Integrations intro, Model training index)
[ ] Added to examples README

🧪 Test Configuration

OS:
Python version: 3.9.12
Neptune version: 0.16.7
Affected libraries with version:

transformers==4.22.0 datasets==2.5.1 torch==1.12 scipy==1.6.3 scikit-learn==0.24.0

✔ Post-merge checklist
These tasks should be done after the code is merged to main. Create a subtask under the main ClickUp task to have these on your radar and share the subtask here.
Post-merge subtask: (ClickUp/JIRA task name)

[ ] Update relevant blogs with impacted code/functionality (Contact @Patrycja-J for the list of blogs)
[ ] Add functionality under the Neptune column of the competitor comparison sheet (Coordinate with @SiddhantSadangi)
[ ] Update integration README (Contact @Patrycja-J)

Closing in favour of #118

repo: neptune-ai/examples


text:
Add copy/cut/paste buttons to code and sprite editor

Being able to use TIC on Android is great, however CTRL+C, CTRL+V do not work making it difficult to create animations, or fixing some code issues without redrawing and retyping.
Maybe we can have cut, copy and paste buttons along the top right of the header bar? Or with the other tools in the sprite editor?
Undo and redo would be a nice touch as well.

Do you use TIC on Android with external keyboard?

I have one that I use sometimes but it can be clunky when working from the couch,  I've never tried the hotkeys on Android with the external keyboard however. I do know that using hacker's keyboard and pressing ctrl+c, ctrl+v does nothing. When using other apps these hotkeys work fine with the soft-keyboard.

ok, will try to fix ctrl+c ctrl+v on hacker's keyboard at first

Cool thanks! Also, if we have a few feature request, should we open issues for each of them? Or is there a better place for feature requests?

I think Github is a good place for feature requests.

I installed hacker's keyboard and noticed that ctrl+c works on my device, cannot reproduce :(
As variant I added other shortcuts shift+del ctrl+insert shift+insert to cut/copy/paste.
Also I added small toolbar with cut copy paste undo redo buttons to all the editors.
Here is an example it looks in .19

closing on .19

Thank you for the toolbar! And ctrl+c, ctrl+v does not work on both of my devices, a Moto G4 and a Galaxy Tab 4. Here's a short video of it not working. Results are the same on both devices: https://youtu.be/Ld-3TXwWCbA

hmm, try to go to
settings > language and input > hacker's keyboard settings > ctrl key code > select 'left ctrl'
and try to reproduce

That was it. Working now. Sorry!

no problem 😃

authors: nesbox trelemar


text:
Release 1.0?

We are very happy with UnionArgParser and use it in production. Any idea when it may get released in 1.0? I'm asking because in upgrading from 0.8.7 to 0.9.0 I ran into a breaking renaming, which is allowed under the rules of semantic versioning before 1.0, but would like to see this stabilized because we do use it in production.

Sounds reasonable. It would be even greater if I could couple a 1.0 with a name change (see #29).

Just pushed Argu version 1.0

authors: eiriktsarpalis jackfoxy

repo: nessos/UnionArgParser


text:
Discover Developer Tools

https://github.com/nesterone/sf-eng-init-gl-spring-2016/blob/master/00-bootcamp/04-tools-for-development/tools-for-development.md#workshop-discover-developer-tools


text:
Implement NEP 2

This is a reference implementation of NEP 2.

:+1:

repo: nestproject/Inquiline


text:
Policy: Infrastructure

For each feature that we are defining in our data model (VRF-Lite, ACLs, RouteMaps etc...) we need to design the infrastructure to do the following:

Translate datamodel to jinja2 template
Translate jinja2 rendered CLI to dcnm_policy module

The initial part of this issue was completed by #178. Subsequent parts will be completed by #154 #155 #156 #157 #158

authors: mikewiebe mtarking

repo: netascode/ansible-dc-vxlan


text:
Add "filename" as a supported template variable to the "summary" configuration

Is your feature request related to a problem? Please describe.
I would like to use the file name as the title for my posts in the Netlify CMS interface. Extracting the title to be used from the file's body does not appear to be possible.
Describe the solution you'd like
{{filename}} is a template tag available in Netlify CMS. However, for whatever reason, this variable cannot be used for summary in the configuration file (it will always be blank). Adding support for this, making it possible to set a file name as the summary of a post, would solve the problem.
(e.g. summary: "{{filename}}")
Describe alternatives you've considered
The file name (without extention) and the first H1 markdown header in my files are in my particular case always equal. I tried to extract this header from the body of the files, but this does not appear to be possible.
Additional context
Attempting to use summary: "{{filename}}" in the config.yml file results in blank titles.

This issue is a result of this topic on Netlify Community.

Thank you very much @erezrokah. 😄🥳

We added those (filename, extension) recently in other places, but didn't port it to the exiting summary configuration.

repo: netlify/netlify-cms


text:
fix(config): stop throwing on config.yml 404, fix manual init

Summary

We weren't catching the error when config.yml was 404, so manual init without a config file wasn't possible.

Deploy preview for netlify-cms-www ready!
Built with commit 37c83186af5a70b1f5446d40ce478fda3fa68be3
https://deploy-preview-1801--netlify-cms-www.netlify.com

Deploy preview for cms-demo ready!
Built with commit 37c83186af5a70b1f5446d40ce478fda3fa68be3
https://deploy-preview-1801--cms-demo.netlify.com

authors: erquhart verythorough


text:
WIP - Force trailing slash

- Summary
Attempt at fixing #332 with React Router, does not work currently. Needs further investigation.
- Description for the changelog
If the path name does not end in a single trailing slash when the app is loaded redirect to a URL with a single trailing slash before loading the rest of the app.

@erquhart thanks for the title update - I had been meaning to do that!

Closing this - considering that we don't know where folks will put the CMS and how their build system will interact with it, we'll need a more considered approach to solve this issue (if at all).

authors: erquhart josephearl


text:
NETOBSERV-1693 Prompt for copying files on exit followup

Description
@Amoghrd would that work for you ?
--copy=true|false|prompt

by default the prompt is asked at the end of the collection. If the user specify --copy=true or --copy=false, the corresponding action is done without prompt.
Dependencies

n/a
Checklist
If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that.

[X] Is this PR backed with a JIRA ticket? If so, make sure it is written as a title prefix (in general, PRs affecting the NetObserv/Network Observability product should be backed with a JIRA ticket - especially if they bring user facing changes).
[ ] Does this PR require product documentation?

[ ] If so, make sure the JIRA epic is labelled with "documentation" and provides a description relevant for doc writers, such as use cases or scenarios. Any required step to activate or configure the feature should be documented there, such as new CRD knobs.

[ ] Does this PR require a product release notes entry?

[ ] If so, fill in "Release Note Text" in the JIRA.

[ ] Is there anything else the QE team should know before testing? E.g: configuration changes, environment setup, etc.

[ ] If so, make sure it is described in the JIRA ticket.

QE requirements (check 1 from the list):

[X] Standard QE validation, with pre-merge tests unless stated otherwise.
[ ] Regression tests only (e.g. refactoring with no user-facing change).
[ ] No QE (e.g. trivial change with high reviewer's confidence, or per agreement with the QE team).

/ok-to-test

The copy option does not show up in help and also in env log lines. Otherwise works as expected!

@msherif1234 & @Amoghrd
Rebased and added help, doc and an echo when param is set. Thanks for your feedback !

/lgtm

Works as expected.
/label qe-approved

authors: Amoghrd jpinsonneau msherif1234

repo: netobserv/network-observability-cli


text:
Adapt columns in frontend config with changes in plugin

depends on https://github.com/netobserv/network-observability-console-plugin/pull/633

/approve


text:
Updates for SCIONLab update

This change is

.circleci/config.yml, line 35 at r8 (raw file):
Previously, FR4NK-W wrote…

ubuntu-1604:202007-01

Could we use the newer image ubuntu-2004:202008-01, aka ubuntu-2004:202010-01?

Unfortunately, the new image comes with go 1.15, which breaks topology generation. What do you think, should we install go 1.14 on ubuntu-2004:202010-01 or should we just stick with ubuntu-1604:202007-01 for the time being?

.circleci/config.yml, line 35 at r8 (raw file):
Previously, FR4NK-W wrote…

should we just stick with ubuntu-1604:202007-01 for the time being

let's stick with the older image and do the switch later together with the change to Go 1.15+
Would have been nice though.

I agree, thanks!

repo: netsec-ethz/scion-apps


text:
change egress router to allow user to extend the router handler

allow router hander to be extend.
tuning ingress-proxy hanlder

 change egress router to allow user to extend the router handler light-4j master


text:
Message Types vs Data Blocks

Hey! Just started working with this package, and hoping to get some usage advice! I'm confused about the use of Message Types.
Most uses of Message Types in the examples have special classes for each one, with unique serialization functions. Are Message types supposed to be entirely different serializations, or descriptors of different use cases for a message?
In my old netcode solution, I would pass a number for the event type. So "20" for activating a certain power, and "21" for building a wall. In Yojimbo, would these events be different message types? Or should I keep with the "number for type" system?

To answer my own question, it's an emphatic YES. My main confusion was about message serializations:
class TestMessage : public yojimbo::Message {
public:
    int m_data;

    TestMessage() :
        m_data(0) {}

    template <typename Stream>
    bool Serialize(Stream& stream) {
        serialize_int(stream, m_data, 0, 512);
        return true;
    }

    YOJIMBO_VIRTUAL_SERIALIZE_FUNCTIONS();
};

Here I read serialize_int and thought it was WRITING to m_data. But it's actually the opposite: Messages are sent as streams, and m_data is not a stream---yet!
serialize_int takes in a number and WRITES it to the stream, now ready to send it along. When received by the client, it'll automatically unpack the stream into its original m_data variables.
Here's my example of a message with multiple pieces of data:
struct PlayerStateMessage : public Message
{
    short x;
    short y;
    uint8_t state;

    PlayerStateMessage() : x(0), y(0), state(0) {}

    template <typename Stream> bool Serialize( Stream & stream )
    {
        serialize_int(stream, x, -32767, 32767);
        serialize_int(stream, y, -32767, 32767);
        serialize_int(stream, state, 0, 256);
        return true;
    }

    YOJIMBO_VIRTUAL_SERIALIZE_FUNCTIONS();
};

If you have multiple event types (player dead or whatever), every id will use different variables right? Turning a player invisible won't require an X and Y input! So you make a different class to serialize a different set of inputs!
I hope this helps anyone else looking to use this package!

repo: networkprotocol/yojimbo


text:
Building for Android

Hey Glenn,
how to build yojimbo for Android on Windows?
Alex

I don't know?

I recently tried and failed on windows, can't remember the details. Ended up installing dualboot Linux, after that it was super smooth. You could try a VM if you're feeling lucky.

Hey Rick,
thanks for the tip, can you provide some details on how do you accomplish that,
and may send me your compiled lib so I can test my UE4 integration on Android quickly.
Thanks in advance!
Alex

Was part of a paid contract, so can't just give you the libs really.
libsodium:
from root of repo
export ANDROID_NDK_HOME=/blah/blah/Sdk/ndk-bundle
./dist-build/android-armv7-a.sh
mbedtls:
just use cmake to generate make files with android toolchain - e.g. https://github.com/taka-no-me/android-cmake/blob/master/android.toolchain.cmake

Nice one RickLamb, appreciate the help.

Has anyone written up a comprehensive explanation of how to get this running on Android? I'm currently looking to compile this on both iOS and Android from OSX, but running into a lot of issues with Android due to needing libsodium  and mbedtls compiled for Android as well.

When you get it working, I am happy to accept pull requests. -- cheers

authors: Alex-G MattFoley RickLamb gafferongames


text:
Buffer size is limited that can produce leaks of messages in output

Example output
See at
describe-ns-hcsmb.log
as you can see describe is not full.
Steps to reproduce

Create a new unit test
Create a bash instance
Write a file with text that has size more than 10000 bytes
Verify that we don't lose any byte in the output

Tried to write files with size more then 1MB using bash instance. Result: no output leaks.
Tried to reduce timeout for log queries from kubernetes. Current timeout might be not enough to write all logs and pod describes. Result: even 80ms is enough to retrieve descriptions from all pods.

It looks like everything is ok. Closing issue.

authors: NikitaSkrynnik denis-tingaikin

repo: networkservicemesh/gotestmd


text:
Use cloudtest from latest master

Signed-off-by: Artem Belov artem.belov@xored.com
Description
Motivation and Context
Pull cloudtest with fix for https://github.com/networkservicemesh/cloudtest/pull/19
How Has This Been Tested?

[ ] Covered by existing integration testing
[ ] Added integration testing to cover
[ ] Tested locally
[ ] Have not tested

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.

Failures not related to changes, and we need fix from cloud test for proper interdomain testing so merging.

authors: artem-belov haiodo

repo: networkservicemesh/networkservicemesh


text:
linux连接校园网

这个如果服务器没法联网，该怎么弄呢

是指没法下载ipgw的话，参考 #41

authors: henuyzf unbyte

repo: neucn/ipgw


text:
Obsolete API

After importing the asset from the AssetStore it tells me "The project uses obsolete API".

Yes, it is fixed by this commit https://github.com/neuecc/LINQ-to-GameObject-for-Unity/commit/e8b1e2d09a59c293a88ad010ebe7e273ca7e7d25
I'll upload new package on AssetStore.

authors: NoxMortem neuecc

repo: neuecc/LINQ-to-GameObject-for-Unity


text:
An option to wrap queries with r.wait()

Because some use cases demand a incremental id which needs periodical rebalancing due to RethinkDB  only supporting range sharding

Let's track things on the rethinkdb tracker for this one.
https://github.com/rethinkdb/rethinkdb/issues/5208
I'm midly convince that this is a good idea. That means that in case you loose enough server, you will just wait forever.

authors: neumino thelinuxlich

repo: neumino/rethinkdbdash


text:
Add Pose Estimator Support for Jetsons

I tried to run existing pose estimation algorithms on Jetson devices as what @alpha-carinae29 has done for X86, GPU and Coral. I’m going to write my results and issues here.

First, I started with the NVIDIA-AI-IOT/trt_pose project. There are several pretrained models on their repo and I could easily make a dockerfile to run it using their instruction.
It is reported to work with 12-22 fps on Jetson Nano but its pose estimation accuracy on frames from surveillance cameras wasn’t good enough for our problem due to the small object sizes and the best result from this project was with the pretrained densenet121_baseline_att_256x256_B model with the frame rate of 9 fps.

I continued this task with OpenPifPaf project, as I found out it has the best results for our task. I decided to export openpifpaf model as ONNX format and then generate a TensorRT engine from that onnx model.
To export onnx from openpifpaf I used openpifpaf 0.10.0 and this command:
python3 -m openpifpaf.export_onnx --checkpoint resnet50 --outfile resnet50-openpifpaf.onnx --no-polish

I used ONNX-TensorRT repo to convert onnx model. Since I had jetpack 4.3 (TensorRT 6.0.1) installed on my Jetson devices, I used 6.0-full-dims tag.
After getting lots of error I used these instruction to build ONNX-TensorRT on a smart-distancing l4t docker for Jetson:
docker run --runtime nvidia --privileged -it -v /usr/include/aarch64-linux-gnu/:/usr/include/aarch64-linux-gnu/ -v $PWD:/repo neuralet/onnx2trt
git clone https://github.com/onnx/onnx-tensorrt.git
cd onnx-tensorrt
git checkout 6.0-full-dims
mkdir build
cd build
cmake ../ -DCUDA_INCLUDE_DIRS=/usr/local/cuda-10.0/include -DTENSORRT_INCLUDE_DIR=/usr/include/aarch64-linux-gnu -DTENSORRT_LIBRARY_INFER_PLUGIN=/usr/lib/aarch64-linux-gnu/libnvinfer_plugin.so -DTENSORRT_ROOT=/usr/src/tensorrt/ -DGPU_ARCHS="53" -DCUDNN_INCLUDE_DIR=/usr/lib/aarch64-linux-gnu -DTENSORRT_LIBRARY_INFER=/usr/lib/aarch64-linux-gnu/libnvinfer.so
make -j4
make install

-DGPU_ARCHS="53" for Jetson Nano and -DGPU_ARCHS="62" for Jetson TX2

ERROR:  make[2]: * No rule to make target '/usr/lib/aarch64-linux-gnu/libnvinfer_plugin.so', needed by 'libnvonnxparser.so.6.0.1'.  Stop
Solve with:
ln -s /usr/lib/aarch64-linux-gnu/libnvinfer.so.6 /usr/lib/aarch64-linux-gnu/libnvinfer.so
ln -s /usr/lib/aarch64-linux-gnu/libnvinfer_plugin.so.6 /usr/lib/aarch64-linux-gnu/libnvinfer_plugin.so

And finally TensorRT generation was performed using command bellow:
onnx2trt resnet50-openpifpaf -o resnet50-openpifpaf.trt

Tips:

As TensorRT engine is built based on target GPU platform it is required to be generated and used on target device.
You can see onnx2trt help using -h argument and you can set max_batch_size using -b and model_data_type_bit_depth using -d to 32 for float32 and 16 for float16

repo: neuralet/smart-social-distancing


text:
Add print start up message as well as top-level-folder state to relevant methods.

This PR sets a 'welcome' message on project initialisation. This at the moment only shows the current top-level working directory. However, we don't want to show this every time a CLI command is run (the CLI works by initialising the API and running the required function). So, this is turned off for CLI calls.
Also, the show_top_level_folder method is called when all relevant functions are run (make_sub_folders and upload / download transfer methods that rely on the working top level folder).

Thanks a lot @alessandrofelder, that is correct this is not displayed for the CLI. The reason is that it will be shown for every command which could be annoying (e.g. if using show_local_path its not necessary to see the entire welcome message. That being said, from the CLI there is no way to get this information. For now, this isn't a problem as it only prints the top level folder which can be accessed by show-top-level-folder. But it might be worth exposing a dedicated shower command if more things are added.

Added a couple for fixed related to this PR in #161

repo: neuroinformatics-unit/datashuttle


text:
Ideas for upcoming hackathons

Please throw out any ideas for hackathons here to discuss. I know @agahkarakuzu already has one suggestion for this month's BrainHack.

I could take a look at PSOM
We could also discuss whether it make sense to include MINC support
I was also thinking of getting started on integrating an ASL toolbox

@ileppe MINC support could be great! Is the best way still to go through NIAK? If so, we'll have to alert the user that they have to open MATLAB from the command-line on Macs to access the MINC tool paths that NIAK uses, not sure how it works for Windows OS's.

@ileppe I just had a short appear.in meeting with @agahkarakuzu, and we briefly touched on the upcoming hackathon. Taking a look at the schedule, there is a brainstorming session earlier in the day before the actual "hacking" begins.
@agahkarakuzu suggested we wait until that session to decide what to do to see if people have ideas for qMRLab, have insight on how to implement some of the suggestions here, or would be willing to jump on the project. I'm opening my day to help you all out when/if needed, and will likely jump on our appear.in channel if either of you want to work/chat/hack.

In addition, for BIDS compatibility works:
There is a matlab file collection for generating .json files for some data types. These can be used as a start point.
@jcohenadad  I see lots of value in bringing BIDS compatibility to qMRLab. This is why I would like to use upcoming brainhack as an opportunity to lay the base for BIDS compatibility.  I've seen your suggestions on BIDS 2.0 for MT. I know that specifications are already available for  T1map, T2map and T1rho. Yet, still many qMR specifications are missing.
How do you suggest (or should) we propose more qMR specifications? For example, would proposing a qmr folder in addition to dif, anat and func be crying for the moon?
I'd be glad if you can suggest action items that you think are of high priority for BIDS compatibility efforts.

Hi - I have been meaning to get involved with the BIDS 2.0 discussion but have lacked time.
I recently updated QUIT to take most of the input in JSON format - so for instance, with DESPOT1, you need to give a parameter file that looks like:
{
    "SPGR" : {
        "TR": 0.01,
        "FA": [5, 10, 15]
    }
}

It turns out JSON is pretty nice for small parameter files like this.
I think the biggest issue for qMR + BIDS is the file/folder layout. Currently BIDS seems to be going down the route of being quite specific about how raw data needs to be laid out - I think this may become a headache when the huge variety of qMR methods is considered!

@spinicist Hi!
Indeed, json itself is quite useful when considered as a struct that can be read across platforms. In your example, do you generate them manually (e.g. "FA": [5, 10, 15]) ?
As you noted, file format (NIFTI accompanied by a json) and standardized folder structure are central to BIDS. But this actually can be the solution to deal with the huge variety, although it is going to take some dedicated description effort at the beginning.
What I see is that BIDS definitions are created with mostly DTI and fMRI in mind. They have useful definitions for semantic categorization of these data types (e.g. task, event). Accordingly, running the same sequence multiple times (Run definition) is defined as an uninterrupted repetition of data acquisition that has the same acquisition parameters and task. Although repeating same sequence with different parameters is desirable in our case, it is not well captured by current BIDS definitions.
When I think of a complicated file/folder layout, I imagine an MTsat acqusition for example. Where 1st and 2nd acquisition shares the same FA and differ in MT pulse state, then 3rd and 4th differ in FA, all acquired with the same sequence. Let's think of a case where a user would put all these series under one folder along with two acquisitions for B1 map:
-- dicomdir
--- ser01 (mt off FA 10)
--- ser02 (mt on FA 10)
--- ser03 (mt off FA 20)
--- ser04 (mt off FA 30)
--- ser05 (b1 angle 1)
--- ser06 (b1 angle 2)
According to BIDS, these should all go under the anat folder. Hacking the present definitions we can convert this data into:
-- anat
--- sub-control01_task-qAcquisition_event-MTsat_run-01.nii.gz
--- sub-control01_task-qAcquisition_event-MTsat_run-02.nii.gz
--- sub-control01_task-qAcquisition_event-MTsat_run-03.nii.gz
--- sub-control01_task-qAcquisition_event-MTsat_run-04.nii.gz
--- sub-control01_task-qAcquisition_event-B1dam_run-01.nii.gz
--- sub-control01_task-qAcquisition_event-B1dam_run-01.nii.gz
Having JSON files attaining the same name with respective nii.gz., parsing this data for MTsat fitting would be quite easy.  Having qMR specific descriptions would make it even better, instead of using fMRI specific descriptions to hack our way.
In this scenario, the obvious problem is  to convert from dicomdir to anat  without causing too much trouble to the users. Fortunately, there is heudiconv. Some contribution to their library for the heuristics of qMR data conversion may solve this issue.
I brought MTsat case as an example, it  may not be the most optimal way to organize data. But if we can systematically do this kind of arrangement for all qMR models that we support, we can even tell which mappings are technically possible by validating the raw data provided by user.

@agah - Yes, at the moment I write the input files manually. For the quantitative sequences I have written for GE not all the parameters needed are stored in the DICOM headers.
This is because I generally write sequences to acquire all needed volumes in one series. On GE this is a particularly good approach to ensure all the transmit/receive gains and tuning are the same (manual prescan is a pain to use). To use your MTSat example, I have a sequence that will easily acquire all the MT volumes in one series, and I have structured QUIT to generally use 4D NIFTIs as input. Similarly for DESPOT all flip-angles are acquired in one series, and there’s not an easy way I am aware of to write all the flip-angles into the headers.
It sounds like this doesn’t fit particularly well with BIDS conventions but I wouldn’t want to drop it, it’s incredibly convenient - and for instance it lets you use mcflirt for motion compensation which is much more straightforward than running flirt on everything individually.
I need to read the BIDS standards more thoroughly but if we could end up with both QUIT and qMRLab working using the same input files that would be amazing.

On 24 Apr 2018, at 20:55, Agah notifications@github.com wrote:
@spinicist Hi!
Indeed, json itself is quite useful when considered as a struct that can be read across platforms. In your example, do you generate them manually (e.g. "FA": [5, 10, 15]) ?
As you noted, file format (NIFTI accompanied by a json) and standardized folder structure are central to BIDS. But this actually can be the solution to deal with the huge variety, although it is going to take some dedicated description effort at the beginning.
What I see is that BIDS definitions are created with mostly DTI and fMRI in mind. They have useful definitions for semantic categorization of these data types (e.g. task, event). Accordingly, running the same sequence multiple times (Run definition) is defined as an uninterrupted repetition of data acquisition that has the same acquisition parameters and task. Although repeating same sequence with different parameters is desirable in our case, it is not well captured by current BIDS definitions.
When I think of a complicated file/folder layout, I imagine an MTsat acqusition for example. Where 1st and 2nd acquisition shares the same FA and differ in MT pulse state, then 3rd and 4th differ in FA, all acquired with the same sequence. Let's think of a case where a user would put all these series under one folder along with two acquisitions for B1 map:
-- dicomdir
--- ser01 (mt off FA 10)
--- ser02 (mt on FA 10)
--- ser03 (mt off FA 20)
--- ser04 (mt off FA 30)
--- ser05 (b1 angle 1)
--- ser06 (b1 angle 2)
According to BIDS, these should all go under the anat folder. Hacking the present definitions we can convert this data into:
-- anat
--- sub-control01_task-qAcquisition_event-MTsat_run-01.nii.gz
--- sub-control01_task-qAcquisition_event-MTsat_run-02.nii.gz
--- sub-control01_task-qAcquisition_event-MTsat_run-03.nii.gz
--- sub-control01_task-qAcquisition_event-MTsat_run-04.nii.gz
--- sub-control01_task-qAcquisition_event-B1dam_run-01.nii.gz
--- sub-control01_task-qAcquisition_event-B1dam_run-01.nii.gz
Having JSON files attaining the same name with respective nii.gz., parsing this data for MTsat fitting would be quite easy. Having qMR specific descriptions would make it even better, instead of using fMRI specific descriptions to hack our way.
In this scenario, the obvious problem is to convert from dicomdir to anat without causing too much trouble to the users. Fortunately, there is heudiconv. Some contribution to their library for the heuristics of qMR data conversion may solve this issue.
I brought MTsat case as an example, it may not be the most optimal way to organize data. But if we can systematically do this kind of arrangement for all qMR models that we support, we can even tell which mappings are technically possible by validating the raw data provided by user.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

I need to read the BIDS standards more thoroughly but if we could end up with both QUIT and qMRLab working using the same input files that would be amazing.

Agreed - this definitely looks like a valuable thing to pursue! I was also just mentioning to Agah last week that it would be very valuable to test fitting the same data (e.g. VFA) with both qMRLab and QUIT to compare the results.

@spinicist thank you very much for chipping in!
@agahkarakuzu in response to this comment: i think the strategy is to show the BIDS community that there is a critical mass of researchers who are not only doing DTI+fMRI. That implies posting on BIDS2.0 suggestion, participating in various BIDS forums, etc. Regarding the creation of a "qmr" folder, i am not a big fan of it, because it will end up being the same trash can as the anat folder. Also, what happens if people have two different sets of scan for qmr? I would instead follow the same philosophy of the anat, dwi and fmri folder, and add others, such as mt (which could be used for qMT, MTsat, MTR, MTCSF, etc.) or despot, etc. But this of course will require some consensus prior to that.
in response to this comment:
I would not necessarily use the fields task and event, but rather describe the different acquisition parameters with the field acq, as exemplified here. So in your example it would be something like:
-- anat
--- sub-control01_acq-MTsat-flipangleXX-TRXX_run-01.nii.gz

@jcohenadad Thank you for the suggestions. I agree that we should show more presence in BIDS threads. Departing from your suggestion for mt, qMRLab's model hierarchy scheme constitutes a good template. Taking that as a basis, I suggest we write a proposal by following BIDS contribution guideline (quoted below) and attract attention to that in BIDS 2.0. Would you find this idea appropriate and useful?

Create a solid draft of your extension by discussing among colleagues.
List on the draft who is leading the effort.
Share the draft in a form of a google doc (remember to share a link that allows anyone to comment) with the bids-discussion mailing list and ask for comments.
Incorporate the feedback, strive for consensus.
Help merging the extension into the main specification.

@agah - Yes, my sequences are available to other GE users. GE launched this website https://collaborate.mr.gehealthcare.com/ a couple of years ago - if people join that, they can then request access to the "Software Sharing Group", which involves signing some legal paperwork with GE. Once that's done, I'm allowed to share everything I have (binaries or source code). It's far better than the old way which involved a legal agreement per sequence per site (yuck). Note that someone at your site will have had to go on the EPIC course to get access (I think).
@jcohenadad I agree that a folder roughly per method/technique is the right idea. The tricky bit comes when methods are inter-related, for instance, for qMT you generally need a T1 map. Should the T1 input files go in a separate folder or with the MT stuff? I'd argue for a separate folder.

@spinicist At our site we use Siemens scanners. But sequence sharing may not be restricted by the Vendor type, have you ever taken a look at Pulseq, an open source platform for pulse sequences. I guess custom written sequences can tap into this for sharing across-vendors.
My choice for inter-related quantifications would be having separate folders. We can have a data explorer that crawls through the directory and check if minimum requirements are met for a certain models.

@mathieuboudreau @ileppe
❗ THIS IS ❗ a highly relevant proposal for adding qMR methods. After mining information regarding the current state of qMR methods in BIDS from the links below, we can populate this proposal with our suggestions.
Here is the BIDS 2.0 document that includes Julien's suggestions for changing sequence name for FLASH to a non-proprietary name and adding magnetization transfer.
A strategic move would be reading Gorgolewski's answers to the qMR related suggestions/questions to understand the way he approaches suggestions:

MP2RAGE, multi echo etc: https://groups.google.com/forum/#!msg/bids-discussion/UrvL4ng3qe8/gb2OjQgmAQAJ

MT, Multi echo and others: https://groups.google.com/forum/#!searchin/bids-discussion/magnetization|sort:date/bids-discussion/l1NOQceKn0Y/EOWDqczCAwAJ

💯 Magnetization Transfer: https://groups.google.com/forum/#!searchin/bids-discussion/magnetization|sort:date/bids-discussion/3KQbXfI9BXk/qebtOhe6AQAJ

Includes another discussion about MT: https://groups.google.com/forum/#!searchin/bids-discussion/magnetization|sort:date/bids-discussion/IdWe0R8OFyw/uwt7yjxgBgAJ

By Julien: https://groups.google.com/forum/#!searchin/bids-discussion/magnetization|sort:date/bids-discussion/Xj5yZCLZvyc/ka6TpXm1AAAJ

SWI thread (also questioning the fitness of anat folder for their purpose): https://groups.google.com/forum/#!searchin/bids-discussion/t1$20mapping|sort:date/bids-discussion/AMQZMCGF9Ek/mimVKOPlAgAJ

MTR: https://groups.google.com/forum/#!searchin/bids-discussion/quantitative|sort:date/bids-discussion/qZpt3qaVmyY/-aZnkHduBwAJ

ASL and other perfusion methods: https://groups.google.com/forum/#!searchin/bids-discussion/quantitative|sort:date/bids-discussion/WCkUNCF8rxQ/qlLVUDYSBAAJ

Announcement that lists new additions: https://groups.google.com/forum/#!searchin/bids-discussion/quantitative|sort:date/bids-discussion/1jLKXX-hp7Q/wZmXKGryBAAJ

https://groups.google.com/forum/#!searchin/bids-discussion/quantitative|sort:date/bids-discussion/1jLKXX-hp7Q/wZmXKGryBAAJ

Rethinking multi echo by Gorgolewski: https://groups.google.com/forum/#!searchin/bids-discussion/julien|sort:date/bids-discussion/omJK3sPX9Ok/bJ7bU94ZCQAJ

P.S. Tibor Auer is a name that comes up a lot whenever qMR related topics are discussed.

Thanks @agah, that‘s a lot of reading for me tomorrow.
I’ve not come across Tibo Auer in the literature but looks like he’s at Royal Holloway which is pretty close to KCL, it’s a small world!

On 26 Apr 2018, at 18:06, Agah notifications@github.com wrote:
@mathieuboudreau @ileppe
❗ THIS IS ❗ a highly relevant proposal for adding qMR methods. After mining information regarding the current state of qMR methods in BIDS from the links below, we can populate this proposal with our suggestions.
Here is the BIDS 2.0 document that includes Julien's suggestions for changing sequence name for FLASH to a non-proprietary name and adding magnetization transfer.
A strategic move would be reading Gorgolewski's answers to the qMR related suggestions/questions to understand the way he approaches suggestions:
MP2RAGE, multi echo etc: https://groups.google.com/forum/#!msg/bids-discussion/UrvL4ng3qe8/gb2OjQgmAQAJ
MT, Multi echo and others: https://groups.google.com/forum/#!searchin/bids-discussion/magnetization|sort:date/bids-discussion/l1NOQceKn0Y/EOWDqczCAwAJ
💯 Magnetization Transfer: https://groups.google.com/forum/#!searchin/bids-discussion/magnetization|sort:date/bids-discussion/3KQbXfI9BXk/qebtOhe6AQAJ
Includes another discussion about MT: https://groups.google.com/forum/#!searchin/bids-discussion/magnetization|sort:date/bids-discussion/IdWe0R8OFyw/uwt7yjxgBgAJ
By Julien: https://groups.google.com/forum/#!searchin/bids-discussion/magnetization|sort:date/bids-discussion/Xj5yZCLZvyc/ka6TpXm1AAAJ
SWI thread (also questioning the fitness of anat folder for their purpose): https://groups.google.com/forum/#!searchin/bids-discussion/t1$20mapping|sort:date/bids-discussion/AMQZMCGF9Ek/mimVKOPlAgAJ
MTR: https://groups.google.com/forum/#!searchin/bids-discussion/quantitative|sort:date/bids-discussion/qZpt3qaVmyY/-aZnkHduBwAJ
ASL and other perfusion methods: https://groups.google.com/forum/#!searchin/bids-discussion/quantitative|sort:date/bids-discussion/WCkUNCF8rxQ/qlLVUDYSBAAJ
Announcement that lists new additions: https://groups.google.com/forum/#!searchin/bids-discussion/quantitative|sort:date/bids-discussion/1jLKXX-hp7Q/wZmXKGryBAAJ
https://groups.google.com/forum/#!searchin/bids-discussion/quantitative|sort:date/bids-discussion/1jLKXX-hp7Q/wZmXKGryBAAJ
Rethinking multi echo by Gorgolewski: https://groups.google.com/forum/#!searchin/bids-discussion/julien|sort:date/bids-discussion/omJK3sPX9Ok/bJ7bU94ZCQAJ
P.S. Tibor Auer is a name that comes up a lot whenever qMR related topics are discussed.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@agah / @mathieuboudreau I've had time to read through some of those links / discussions now and what I see there does not encourage me. A lot of the discussion seems to be from people without much experience of quantitative acquisition methods. The BEP001 proposal seems to insist on 3D files only, which is an unnecessary burden in my opinion. Everything in QUIT is structured around 4D files - and my sequences are written to acquired 4D files. Is this something fundamental to BIDS? I assume not as the fMRI files aren't broken down into 3D volumes.
BEP001 also contains barely a handful of example acquisition types - for instance there is no qMT and hence no discussion of offset frequencies. I raise that purely as trying to introduce a filename key for all acquisition parameters is a fool's errand.
I think we definitely all need to get involved in that discussion ASAP!

Happy that you managed to read some of those @spinicist !

A lot of the discussion seems to be from people without much experience of quantitative acquisition methods.

I can say that the awareness regarding the existence of more than one way of obtaining a certain type of map is not there.
What I envision is that regardless of the # of dimensions, minimal file name descriptions to the nifti files with comprehensive JSON file attached to them will be enough to decide how to fit that data. Then we can write scripts to parse 3D volumes into 4D qData (or 2D slices to 3D qVolumes), and ensure that parameters match each volume along the quantitative dimension.  Given the inevitable heterogeneity in the accessible scanners and sequences, I think this is desirable.  In addition, # of dimensions does not have to be fixed thereunder BIDS descriptions.
Upon our brief discussion with @mathieuboudreau, we draw the conclusion that qMT methods are way more tricky to generalize, making boilerplate parsing scheme infeasible. So, qMT may not make the best starting point for discussion compared to the T1, MTR, MTsat, T2 (mono, multiexp) and field maps.
Advantages of BIDS are:

An online validator ensures that user has the correct data
It makes it easy to integrate tools to HPC platforms like open neuro
Opens up the way to describe conversion heuristics (heudiconv), so that a user can bring their raw DICOM images and get BIDS out.

It is possible to achieve 3 even without having an accepted BIDS description. Yet, 1 and 2 brings advantages for standardization. To this end, I agree that we definitely should contribute to those discussions.
I think we should divide the problem into smaller pieces, reach an internal qMR committee consensus per method and submit our suggestions.

@spinicist My 2 cents with @agahkarakuzu  about our involvement in BIDS for qMR methods is that if we have both our softwares follow some of the BIDS recommendation we're going to give even before they official get approved, it'll those give more weight in the discussion. We need to voice our opinions of what we think qMR's needs are, as I agree that it doesn't seem to be mostly qMR ppl guiding the direction of the wind on that project.

authors: agahkarakuzu ileppe jcohenadad mathieuboudreau spinicist

repo: neuropoly/qMRLab


text:
Russian keyboard layout doesn't work in Microsoft's RDP client for iPad

Description
I use XRDP 0.9.15-1.4 (with xorgxrdp 0.2.15-1.4) from the OSS repository for openSUSE Tumbleweed. On the remote computer, I have KDE 5 Plasma desktop with Russian and US English layouts enabled.
When connecting from the Windows 10 built-in RDP client, both layouts work and I can switch them by Shift+Ctrl or by pressing RU/EN in the system tray. However, Russian layout only works with Xorg session. With Xvnc session, I get English letters no matter what layout I see in the Plasma system tray, i.e., switching layouts in Plasma has no effect. (I don't need Xvnc, so it doesn't disturb me.) Another point is that I need to have English layout on the client computer when connecting, otherwise I can only type Russian letters, so I can't enter my password. Switching client layout after connection has no effect in the login dialog and both Xorg and Xvnc sessions.
When connecting from iPad client (I use Russian version), I cannot type Russian letters using Russian layout on iPad. I have tested it with different combinations of sessions and local/remote layouts.

Session
Client layout (iOS keyboard)
Remote layout (Plasma desktop)
What I get when pressing keys

Xorg
English
English
English letters

Xorg
English
Russian
Russian letters

Xorg
Russian
English
Nothing

Xorg
Russian
Russian
Nothing

Xvnc
English
English
English letters

Xvnc
English
Russian
English letters

Xvnc
Russian
English
Nothing

Xvnc
Russian
Russian
Nothing

'Nothing' means that I hear a feedback sound from the iOS keyboard, but nothing happens on the remote computer. With the second combination (Xorg, EN client, RU remote), English letters map to Russian letters according to the main Russian layout: q->й, w->ц etc. It would be fine with a physical keyboard, but on a tablet, there are no Russian letters on the keys, and also some letters map to special characters ([->х, ]->ъ, ;->ж etc), which are moved to an auxiliary keyboard. (I suppose that the same mapping also happens on the Windows client, but it's OK there.)
This is my configuration files from /etc/xrdp. They are all owned by root:root and have access rights -rw-r--r--

xrdp_keyboard.ini

; default
[default]
; keyboard_type and keyboard_subtype is not read for default section. It
; is only a placeholder to keep consistency. Default model/variant are
; platform dependent, and could be overridden if needed.
keyboard_type=0
keyboard_subtype=0

; user could override variant and model, but generally they should be inferred
; automatically based on keyboard type and subtype
;variant=
;model=

; A list of supported RDP keyboard layouts
rdp_layouts=default_rdp_layouts
; The map from RDP keyboard layout to X11 keyboard layout
layouts_map=default_layouts_map

[default_rdp_layouts]
rdp_layout_us=0x00000409
rdp_layout_us_dvorak=0x00010409
rdp_layout_us_dvp=0x19360409
rdp_layout_dk=0x00000406
rdp_layout_de=0x00000407
rdp_layout_es=0x0000040A
rdp_layout_fi=0x0000040B
rdp_layout_fr=0x0000040C
rdp_layout_it=0x00000410
rdp_layout_jp=0x00000411
rdp_layout_jp=0xe0010411
rdp_layout_jp=0xe0200411
rdp_layout_jp=0xe0210411
rdp_layout_kr=0x00000412
rdp_layout_no=0x00000414
rdp_layout_pl=0x00000415
rdp_layout_br=0x00000416
rdp_layout_ru=0x00000419
rdp_layout_se=0x0000041D
rdp_layout_ch=0x00000807
rdp_layout_ch_fr=0x0000100C
rdp_layout_gb=0x00000809
rdp_layout_latam=0x0000080A
rdp_layout_be=0x00000813
rdp_layout_pt=0x00000816

;  =
[default_layouts_map]
rdp_layout_us=us
rdp_layout_us_dvorak=dvorak
rdp_layout_us_dvp=us(dvp)
rdp_layout_dk=dk
rdp_layout_de=de
rdp_layout_es=es
rdp_layout_fi=fi
rdp_layout_fr=fr
rdp_layout_it=it
rdp_layout_jp=jp
rdp_layout_kr=kr
rdp_layout_no=no
rdp_layout_pl=pl
rdp_layout_br=br(abnt2)
rdp_layout_ru=ru
rdp_layout_se=se
rdp_layout_ch=ch
rdp_layout_ch_fr=ch(fr)
rdp_layout_gb=gb
rdp_layout_latam=latam
rdp_layout_be=be
rdp_layout_pt=pt

; if two sections have the same keyboard_type and keyboard_subtype, then
; the latter could override the former.
[rdp_keyboard_mac]
keyboard_type=4
keyboard_subtype=3
rdp_layouts=default_rdp_layouts
layouts_map=rdp_layouts_map_mac

[rdp_keyboard_jp]
keyboard_type=7
keyboard_subtype=2
model=pc105
rdp_layouts=default_rdp_layouts
layouts_map=default_layouts_map

[rdp_layouts_map_mac]
rdp_layout_us=us
rdp_layout_us_dvorak=dvorak
rdp_layout_us_dvp=us(dvp)
rdp_layout_dk=dk
rdp_layout_de=de
rdp_layout_es=es
rdp_layout_fi=fi
rdp_layout_fr=fr
rdp_layout_it=it
rdp_layout_jp=jp
rdp_layout_kr=kr
rdp_layout_pl=pl
rdp_layout_br=br(abnt2)
rdp_layout_ru=ru
rdp_layout_se=se
rdp_layout_ch=ch
rdp_layout_ch_fr=ch(fr)
rdp_layout_gb=gb
rdp_layout_latam=latam
rdp_layout_be=be
rdp_layout_pt=pt

[rdp_keyboard_ru]
keyboard_type=4
keyboard_subtype=1
model=pc105
options=grp:alt_shift_toggle
rdp_layouts=default_rdp_layouts
layouts_map=layouts_map_ru

[layouts_map_ru]
rdp_layout_us=us,ru
rdp_layout_ru=us,ru

km-00000409.ini

[noshift]
Key8=65406:0
Key9=65307:27
Key10=49:49
Key11=50:50
Key12=51:51
Key13=52:52
Key14=53:53
Key15=54:54
Key16=55:55
Key17=56:56
Key18=57:57
Key19=48:48
Key20=45:45
Key21=61:61
Key22=65288:8
Key23=65289:9
Key24=113:113
Key25=119:119
Key26=101:101
Key27=114:114
Key28=116:116
Key29=121:121
Key30=117:117
Key31=105:105
Key32=111:111
Key33=112:112
Key34=91:91
Key35=93:93
Key36=65293:13
Key37=65507:0
Key38=97:97
Key39=115:115
Key40=100:100
Key41=102:102
Key42=103:103
Key43=104:104
Key44=106:106
Key45=107:107
Key46=108:108
Key47=59:59
Key48=39:39
Key49=96:96
Key50=65505:0
Key51=92:92
Key52=122:122
Key53=120:120
Key54=99:99
Key55=118:118
Key56=98:98
Key57=110:110
Key58=109:109
Key59=44:44
Key60=46:46
Key61=47:47
Key62=65506:0
Key63=65450:42
Key64=65513:0
Key65=32:32
Key66=65509:0
Key67=65470:0
Key68=65471:0
Key69=65472:0
Key70=65473:0
Key71=65474:0
Key72=65475:0
Key73=65476:0
Key74=65477:0
Key75=65478:0
Key76=65479:0
Key77=65407:0
Key78=65300:0
Key79=65429:0
Key80=65431:0
Key81=65434:0
Key82=65453:45
Key83=65430:0
Key84=65437:0
Key85=65432:0
Key86=65451:43
Key87=65436:0
Key88=65433:0
Key89=65435:0
Key90=65438:0
Key91=65439:0
Key92=65377:0
Key93=0:0
Key94=60:60
Key95=65480:0
Key96=65481:0
Key97=65360:0
Key98=65362:0
Key99=65365:0
Key100=65361:0
Key101=0:0
Key102=65363:0
Key103=65367:0
Key104=65364:0
Key105=65366:0
Key106=65379:0
Key107=65535:127
Key108=65421:13
Key109=65508:0
Key110=65299:0
Key111=65377:0
Key112=65455:47
Key113=65514:0
Key114=269025049:0
Key115=65515:0
Key116=65312:0
Key117=0:0
Key118=269025153:0
Key119=269025093:0
Key120=269025094:0
Key121=269025095:0
Key122=269025096:0
Key123=0:0
Key124=65027:0
Key125=0:0
Key126=65469:61
Key127=0:0
Key128=0:0
Key129=0:0
Key130=0:0
Key131=0:0
Key132=0:0
Key133=0:0
Key134=0:0
Key135=0:0
Key136=0:0
Key137=0:0

[shift]
Key8=65406:0
Key9=65307:27
Key10=33:33
Key11=64:64
Key12=35:35
Key13=36:36
Key14=37:37
Key15=94:94
Key16=38:38
Key17=42:42
Key18=40:40
Key19=41:41
Key20=95:95
Key21=43:43
Key22=65288:8
Key23=65056:0
Key24=81:81
Key25=87:87
Key26=69:69
Key27=82:82
Key28=84:84
Key29=89:89
Key30=85:85
Key31=73:73
Key32=79:79
Key33=80:80
Key34=123:123
Key35=125:125
Key36=65293:13
Key37=65507:0
Key38=65:65
Key39=83:83
Key40=68:68
Key41=70:70
Key42=71:71
Key43=72:72
Key44=74:74
Key45=75:75
Key46=76:76
Key47=58:58
Key48=34:34
Key49=126:126
Key50=65505:0
Key51=124:124
Key52=90:90
Key53=88:88
Key54=67:67
Key55=86:86
Key56=66:66
Key57=78:78
Key58=77:77
Key59=60:60
Key60=62:62
Key61=63:63
Key62=65506:0
Key63=65450:42
Key64=65032:0
Key65=32:32
Key66=65509:0
Key67=65470:0
Key68=65471:0
Key69=65472:0
Key70=65473:0
Key71=65474:0
Key72=65475:0
Key73=65476:0
Key74=65477:0
Key75=65478:0
Key76=65479:0
Key77=65407:0
Key78=65300:0
Key79=65463:55
Key80=65464:56
Key81=65465:57
Key82=65453:45
Key83=65460:52
Key84=65461:53
Key85=65462:54
Key86=65451:43
Key87=65457:49
Key88=65458:50
Key89=65459:51
Key90=65456:48
Key91=65454:46
Key92=65377:0
Key93=0:0
Key94=62:62
Key95=65480:0
Key96=65481:0
Key97=65360:0
Key98=65362:0
Key99=65365:0
Key100=65361:0
Key101=0:0
Key102=65363:0
Key103=65367:0
Key104=65364:0
Key105=65366:0
Key106=65379:0
Key107=65535:127
Key108=65421:13
Key109=65508:0
Key110=65299:0
Key111=65377:0
Key112=65455:47
Key113=65032:0
Key114=269025049:0
Key115=65515:0
Key116=65312:0
Key117=0:0
Key118=269025153:0
Key119=269025093:0
Key120=269025094:0
Key121=269025095:0
Key122=269025096:0
Key123=0:0
Key124=65027:0
Key125=65513:0
Key126=65469:61
Key127=65515:0
Key128=65517:0
Key129=0:0
Key130=0:0
Key131=0:0
Key132=0:0
Key133=0:0
Key134=0:0
Key135=0:0
Key136=0:0
Key137=0:0

[altgr]
Key8=65406:0
Key9=65307:27
Key10=49:49
Key11=50:50
Key12=51:51
Key13=52:52
Key14=53:53
Key15=54:54
Key16=55:55
Key17=56:56
Key18=57:57
Key19=48:48
Key20=45:45
Key21=61:61
Key22=65288:8
Key23=65289:9
Key24=113:113
Key25=119:119
Key26=101:101
Key27=114:114
Key28=116:116
Key29=121:121
Key30=117:117
Key31=105:105
Key32=111:111
Key33=112:112
Key34=91:91
Key35=93:93
Key36=65293:13
Key37=65507:0
Key38=97:97
Key39=115:115
Key40=100:100
Key41=102:102
Key42=103:103
Key43=104:104
Key44=106:106
Key45=107:107
Key46=108:108
Key47=59:59
Key48=39:39
Key49=96:96
Key50=65505:0
Key51=92:92
Key52=122:122
Key53=120:120
Key54=99:99
Key55=118:118
Key56=98:98
Key57=110:110
Key58=109:109
Key59=44:44
Key60=46:46
Key61=47:47
Key62=65506:0
Key63=65450:42
Key64=65513:0
Key65=32:32
Key66=65509:0
Key67=65470:0
Key68=65471:0
Key69=65472:0
Key70=65473:0
Key71=65474:0
Key72=65475:0
Key73=65476:0
Key74=65477:0
Key75=65478:0
Key76=65479:0
Key77=65407:0
Key78=65300:0
Key79=65429:0
Key80=65431:0
Key81=65434:0
Key82=65453:45
Key83=65430:0
Key84=65437:0
Key85=65432:0
Key86=65451:43
Key87=65436:0
Key88=65433:0
Key89=65435:0
Key90=65438:0
Key91=65439:0
Key92=65377:0
Key93=0:0
Key94=124:124
Key95=65480:0
Key96=65481:0
Key97=65360:0
Key98=65362:0
Key99=65365:0
Key100=65361:0
Key101=0:0
Key102=65363:0
Key103=65367:0
Key104=65364:0
Key105=65366:0
Key106=65379:0
Key107=65535:127
Key108=65421:13
Key109=65508:0
Key110=65299:0
Key111=65377:0
Key112=65455:47
Key113=65514:0
Key114=269025049:0
Key115=65515:0
Key116=65312:0
Key117=0:0
Key118=269025153:0
Key119=269025093:0
Key120=269025094:0
Key121=269025095:0
Key122=269025096:0
Key123=0:0
Key124=65027:0
Key125=0:0
Key126=65469:61
Key127=0:0
Key128=0:0
Key129=0:0
Key130=0:0
Key131=0:0
Key132=0:0
Key133=0:0
Key134=0:0
Key135=0:0
Key136=0:0
Key137=0:0

[shiftaltgr]
Key8=65406:0
Key9=65307:27
Key10=33:33
Key11=64:64
Key12=35:35
Key13=36:36
Key14=37:37
Key15=94:94
Key16=38:38
Key17=42:42
Key18=40:40
Key19=41:41
Key20=95:95
Key21=43:43
Key22=65288:8
Key23=65056:0
Key24=81:81
Key25=87:87
Key26=69:69
Key27=82:82
Key28=84:84
Key29=89:89
Key30=85:85
Key31=73:73
Key32=79:79
Key33=80:80
Key34=123:123
Key35=125:125
Key36=65293:13
Key37=65507:0
Key38=65:65
Key39=83:83
Key40=68:68
Key41=70:70
Key42=71:71
Key43=72:72
Key44=74:74
Key45=75:75
Key46=76:76
Key47=58:58
Key48=34:34
Key49=126:126
Key50=65505:0
Key51=124:124
Key52=90:90
Key53=88:88
Key54=67:67
Key55=86:86
Key56=66:66
Key57=78:78
Key58=77:77
Key59=60:60
Key60=62:62
Key61=63:63
Key62=65506:0
Key63=65450:42
Key64=65032:0
Key65=32:32
Key66=65509:0
Key67=65470:0
Key68=65471:0
Key69=65472:0
Key70=65473:0
Key71=65474:0
Key72=65475:0
Key73=65476:0
Key74=65477:0
Key75=65478:0
Key76=65479:0
Key77=65407:0
Key78=65300:0
Key79=65463:55
Key80=65464:56
Key81=65465:57
Key82=65453:45
Key83=65460:52
Key84=65461:53
Key85=65462:54
Key86=65451:43
Key87=65457:49
Key88=65458:50
Key89=65459:51
Key90=65456:48
Key91=65454:46
Key92=65377:0
Key93=0:0
Key94=166:166
Key95=65480:0
Key96=65481:0
Key97=65360:0
Key98=65362:0
Key99=65365:0
Key100=65361:0
Key101=0:0
Key102=65363:0
Key103=65367:0
Key104=65364:0
Key105=65366:0
Key106=65379:0
Key107=65535:127
Key108=65421:13
Key109=65508:0
Key110=65299:0
Key111=65377:0
Key112=65455:47
Key113=65032:0
Key114=269025049:0
Key115=65515:0
Key116=65312:0
Key117=0:0
Key118=269025153:0
Key119=269025093:0
Key120=269025094:0
Key121=269025095:0
Key122=269025096:0
Key123=0:0
Key124=65027:0
Key125=65513:0
Key126=65469:61
Key127=65515:0
Key128=65517:0
Key129=0:0
Key130=0:0
Key131=0:0
Key132=0:0
Key133=0:0
Key134=0:0
Key135=0:0
Key136=0:0
Key137=0:0

[capslock]
Key8=65406:0
Key9=65307:27
Key10=49:49
Key11=50:50
Key12=51:51
Key13=52:52
Key14=53:53
Key15=54:54
Key16=55:55
Key17=56:56
Key18=57:57
Key19=48:48
Key20=45:45
Key21=61:61
Key22=65288:8
Key23=65289:9
Key24=81:81
Key25=87:87
Key26=69:69
Key27=82:82
Key28=84:84
Key29=89:89
Key30=85:85
Key31=73:73
Key32=79:79
Key33=80:80
Key34=91:91
Key35=93:93
Key36=65293:13
Key37=65507:0
Key38=65:65
Key39=83:83
Key40=68:68
Key41=70:70
Key42=71:71
Key43=72:72
Key44=74:74
Key45=75:75
Key46=76:76
Key47=59:59
Key48=39:39
Key49=96:96
Key50=65505:0
Key51=92:92
Key52=90:90
Key53=88:88
Key54=67:67
Key55=86:86
Key56=66:66
Key57=78:78
Key58=77:77
Key59=44:44
Key60=46:46
Key61=47:47
Key62=65506:0
Key63=65450:42
Key64=65513:0
Key65=32:32
Key66=65509:0
Key67=65470:0
Key68=65471:0
Key69=65472:0
Key70=65473:0
Key71=65474:0
Key72=65475:0
Key73=65476:0
Key74=65477:0
Key75=65478:0
Key76=65479:0
Key77=65407:0
Key78=65300:0
Key79=65429:0
Key80=65431:0
Key81=65434:0
Key82=65453:45
Key83=65430:0
Key84=65437:0
Key85=65432:0
Key86=65451:43
Key87=65436:0
Key88=65433:0
Key89=65435:0
Key90=65438:0
Key91=65439:0
Key92=65377:0
Key93=0:0
Key94=60:60
Key95=65480:0
Key96=65481:0
Key97=65360:0
Key98=65362:0
Key99=65365:0
Key100=65361:0
Key101=0:0
Key102=65363:0
Key103=65367:0
Key104=65364:0
Key105=65366:0
Key106=65379:0
Key107=65535:127
Key108=65421:13
Key109=65508:0
Key110=65299:0
Key111=65377:0
Key112=65455:47
Key113=65514:0
Key114=269025049:0
Key115=65515:0
Key116=65312:0
Key117=0:0
Key118=269025153:0
Key119=269025093:0
Key120=269025094:0
Key121=269025095:0
Key122=269025096:0
Key123=0:0
Key124=65027:0
Key125=0:0
Key126=65469:61
Key127=0:0
Key128=0:0
Key129=0:0
Key130=0:0
Key131=0:0
Key132=0:0
Key133=0:0
Key134=0:0
Key135=0:0
Key136=0:0
Key137=0:0
[shiftcapslock]
Key8=65406:0
Key9=65307:27
Key10=33:33
Key11=64:64
Key12=35:35
Key13=36:36
Key14=37:37
Key15=94:94
Key16=38:38
Key17=42:42
Key18=40:40
Key19=41:41
Key20=95:95
Key21=43:43
Key22=65288:8
Key23=65056:0
Key24=113:113
Key25=119:119
Key26=101:101
Key27=114:114
Key28=116:116
Key29=121:121
Key30=117:117
Key31=105:105
Key32=111:111
Key33=112:112
Key34=123:123
Key35=125:125
Key36=65293:13
Key37=65507:0
Key38=97:97
Key39=115:115
Key40=100:100
Key41=102:102
Key42=103:103
Key43=104:104
Key44=106:106
Key45=107:107
Key46=108:108
Key47=58:58
Key48=34:34
Key49=126:126
Key50=65505:0
Key51=124:124
Key52=122:122
Key53=120:120
Key54=99:99
Key55=118:118
Key56=98:98
Key57=110:110
Key58=109:109
Key59=60:60
Key60=62:62
Key61=63:63
Key62=65506:0
Key63=65450:42
Key64=65032:0
Key65=32:32
Key66=65509:0
Key67=65470:0
Key68=65471:0
Key69=65472:0
Key70=65473:0
Key71=65474:0
Key72=65475:0
Key73=65476:0
Key74=65477:0
Key75=65478:0
Key76=65479:0
Key77=65407:0
Key78=65300:0
Key79=65463:55
Key80=65464:56
Key81=65465:57
Key82=65453:45
Key83=65460:52
Key84=65461:53
Key85=65462:54
Key86=65451:43
Key87=65457:49
Key88=65458:50
Key89=65459:51
Key90=65456:48
Key91=65454:46
Key92=65377:0
Key93=0:0
Key94=62:62
Key95=65480:0
Key96=65481:0
Key97=65360:0
Key98=65362:0
Key99=65365:0
Key100=65361:0
Key101=0:0
Key102=65363:0
Key103=65367:0
Key104=65364:0
Key105=65366:0
Key106=65379:0
Key107=65535:127
Key108=65421:13
Key109=65508:0
Key110=65299:0
Key111=65377:0
Key112=65455:47
Key113=65032:0
Key114=269025049:0
Key115=65515:0
Key116=65312:0
Key117=0:0
Key118=269025153:0
Key119=269025093:0
Key120=269025094:0
Key121=269025095:0
Key122=269025096:0
Key123=0:0
Key124=65027:0
Key125=65513:0
Key126=65469:61
Key127=65515:0
Key128=65517:0
Key129=0:0
Key130=0:0
Key131=0:0
Key132=0:0
Key133=0:0
Key134=0:0
Key135=0:0
Key136=0:0
Key137=0:0

km-00000419.ini

[noshift]
Key8=65406:0
Key9=65307:27
Key10=49:49
Key11=50:50
Key12=51:51
Key13=52:52
Key14=53:53
Key15=54:54
Key16=55:55
Key17=56:56
Key18=57:57
Key19=48:48
Key20=45:45
Key21=61:61
Key22=65288:8
Key23=65289:9
Key24=1738:1081
Key25=1731:1094
Key26=1749:1091
Key27=1739:1082
Key28=1733:1077
Key29=1742:1085
Key30=1735:1075
Key31=1755:1096
Key32=1757:1097
Key33=1754:1079
Key34=1736:1093
Key35=1759:1098
Key36=65293:13
Key37=65507:0
Key38=1734:1092
Key39=1753:1099
Key40=1751:1074
Key41=1729:1072
Key42=1744:1087
Key43=1746:1088
Key44=1743:1086
Key45=1740:1083
Key46=1732:1076
Key47=1750:1078
Key48=1756:1101
Key49=1699:1105
Key50=65505:0
Key51=92:92
Key52=1745:1103
Key53=1758:1095
Key54=1747:1089
Key55=1741:1084
Key56=1737:1080
Key57=1748:1090
Key58=1752:1100
Key59=1730:1073
Key60=1728:1102
Key61=46:46
Key62=65506:0
Key63=65450:42
Key64=65513:0
Key65=32:32
Key66=65509:0
Key67=65470:0
Key68=65471:0
Key69=65472:0
Key70=65473:0
Key71=65474:0
Key72=65475:0
Key73=65476:0
Key74=65477:0
Key75=65478:0
Key76=65479:0
Key77=65407:0
Key78=65300:0
Key79=65429:0
Key80=65431:0
Key81=65434:0
Key82=65453:45
Key83=65430:0
Key84=65437:0
Key85=65432:0
Key86=65451:43
Key87=65436:0
Key88=65433:0
Key89=65435:0
Key90=65438:0
Key91=65439:0
Key92=65377:0
Key93=0:0
Key94=47:47
Key95=65480:0
Key96=65481:0
Key97=65360:0
Key98=65362:0
Key99=65365:0
Key100=65361:0
Key101=0:0
Key102=65363:0
Key103=65367:0
Key104=65364:0
Key105=65366:0
Key106=65379:0
Key107=65535:127
Key108=65421:13
Key109=65508:0
Key110=65299:0
Key111=65377:0
Key112=65455:47
Key113=65514:0
Key114=269025049:0
Key115=65515:0
Key116=65312:0
Key117=0:0
Key118=269025153:0
Key119=269025093:0
Key120=269025094:0
Key121=269025095:0
Key122=269025096:0
Key123=0:0
Key124=65027:0
Key125=0:0
Key126=65469:61
Key127=0:0
Key128=0:0
Key129=0:0
Key130=0:0
Key131=0:0
Key132=0:0
Key133=0:0
Key134=0:0
Key135=0:0
Key136=0:0
Key137=0:0

[shift]
Key8=65406:0
Key9=65307:27
Key10=33:33
Key11=34:34
Key12=1712:8470
Key13=59:59
Key14=37:37
Key15=58:58
Key16=63:63
Key17=42:42
Key18=40:40
Key19=41:41
Key20=95:95
Key21=43:43
Key22=65288:8
Key23=65056:0
Key24=1770:1049
Key25=1763:1062
Key26=1781:1059
Key27=1771:1050
Key28=1765:1045
Key29=1774:1053
Key30=1767:1043
Key31=1787:1064
Key32=1789:1065
Key33=1786:1047
Key34=1768:1061
Key35=1791:1066
Key36=65293:13
Key37=65507:0
Key38=1766:1060
Key39=1785:1067
Key40=1783:1042
Key41=1761:1040
Key42=1776:1055
Key43=1778:1056
Key44=1775:1054
Key45=1772:1051
Key46=1764:1044
Key47=1782:1046
Key48=1788:1069
Key49=1715:1025
Key50=65505:0
Key51=47:47
Key52=1777:1071
Key53=1790:1063
Key54=1779:1057
Key55=1773:1052
Key56=1769:1048
Key57=1780:1058
Key58=1784:1068
Key59=1762:1041
Key60=1760:1070
Key61=44:44
Key62=65506:0
Key63=65450:42
Key64=65032:0
Key65=32:32
Key66=65509:0
Key67=65470:0
Key68=65471:0
Key69=65472:0
Key70=65473:0
Key71=65474:0
Key72=65475:0
Key73=65476:0
Key74=65477:0
Key75=65478:0
Key76=65479:0
Key77=65407:0
Key78=65300:0
Key79=65463:55
Key80=65464:56
Key81=65465:57
Key82=65453:45
Key83=65460:52
Key84=65461:53
Key85=65462:54
Key86=65451:43
Key87=65457:49
Key88=65458:50
Key89=65459:51
Key90=65456:48
Key91=65452:44
Key92=65377:0
Key93=0:0
Key94=124:124
Key95=65480:0
Key96=65481:0
Key97=65360:0
Key98=65362:0
Key99=65365:0
Key100=65361:0
Key101=0:0
Key102=65363:0
Key103=65367:0
Key104=65364:0
Key105=65366:0
Key106=65379:0
Key107=65535:127
Key108=65421:13
Key109=65508:0
Key110=65299:0
Key111=65377:0
Key112=65455:47
Key113=65032:0
Key114=269025049:0
Key115=65515:0
Key116=65312:0
Key117=0:0
Key118=269025153:0
Key119=269025093:0
Key120=269025094:0
Key121=269025095:0
Key122=269025096:0
Key123=0:0
Key124=65027:0
Key125=65513:0
Key126=65469:61
Key127=65515:0
Key128=65517:0
Key129=0:0
Key130=0:0
Key131=0:0
Key132=0:0
Key133=0:0
Key134=0:0
Key135=0:0
Key136=0:0
Key137=0:0

[altgr]
Key8=65406:0
Key9=65307:27
Key10=49:49
Key11=50:50
Key12=51:51
Key13=52:52
Key14=53:53
Key15=54:54
Key16=55:55
Key17=56:56
Key18=57:57
Key19=48:48
Key20=45:45
Key21=61:61
Key22=65288:8
Key23=65289:9
Key24=1738:1081
Key25=1731:1094
Key26=1749:1091
Key27=1739:1082
Key28=1733:1077
Key29=1742:1085
Key30=1735:1075
Key31=1755:1096
Key32=1757:1097
Key33=1754:1079
Key34=1736:1093
Key35=1759:1098
Key36=65293:13
Key37=65507:0
Key38=1734:1092
Key39=1753:1099
Key40=1751:1074
Key41=1729:1072
Key42=1744:1087
Key43=1746:1088
Key44=1743:1086
Key45=1740:1083
Key46=1732:1076
Key47=1750:1078
Key48=1756:1101
Key49=1699:1105
Key50=65505:0
Key51=92:92
Key52=1745:1103
Key53=1758:1095
Key54=1747:1089
Key55=1741:1084
Key56=1737:1080
Key57=1748:1090
Key58=1752:1100
Key59=1730:1073
Key60=1728:1102
Key61=46:46
Key62=65506:0
Key63=65450:42
Key64=65513:0
Key65=32:32
Key66=65509:0
Key67=65470:0
Key68=65471:0
Key69=65472:0
Key70=65473:0
Key71=65474:0
Key72=65475:0
Key73=65476:0
Key74=65477:0
Key75=65478:0
Key76=65479:0
Key77=65407:0
Key78=65300:0
Key79=65429:0
Key80=65431:0
Key81=65434:0
Key82=65453:45
Key83=65430:0
Key84=65437:0
Key85=65432:0
Key86=65451:43
Key87=65436:0
Key88=65433:0
Key89=65435:0
Key90=65438:0
Key91=65439:0
Key92=65377:0
Key93=0:0
Key94=124:124
Key95=65480:0
Key96=65481:0
Key97=65360:0
Key98=65362:0
Key99=65365:0
Key100=65361:0
Key101=0:0
Key102=65363:0
Key103=65367:0
Key104=65364:0
Key105=65366:0
Key106=65379:0
Key107=65535:127
Key108=65421:13
Key109=65508:0
Key110=65299:0
Key111=65377:0
Key112=65455:47
Key113=65514:0
Key114=269025049:0
Key115=65515:0
Key116=65312:0
Key117=0:0
Key118=269025153:0
Key119=269025093:0
Key120=269025094:0
Key121=269025095:0
Key122=269025096:0
Key123=0:0
Key124=65027:0
Key125=0:0
Key126=65469:61
Key127=0:0
Key128=0:0
Key129=0:0
Key130=0:0
Key131=0:0
Key132=0:0
Key133=0:0
Key134=0:0
Key135=0:0
Key136=0:0
Key137=0:0

[shiftaltgr]
Key8=65406:0
Key9=65307:27
Key10=33:33
Key11=34:34
Key12=1712:8470
Key13=59:59
Key14=37:37
Key15=58:58
Key16=63:63
Key17=42:42
Key18=40:40
Key19=41:41
Key20=95:95
Key21=43:43
Key22=65288:8
Key23=65056:0
Key24=1770:1049
Key25=1763:1062
Key26=1781:1059
Key27=1771:1050
Key28=1765:1045
Key29=1774:1053
Key30=1767:1043
Key31=1787:1064
Key32=1789:1065
Key33=1786:1047
Key34=1768:1061
Key35=1791:1066
Key36=65293:13
Key37=65507:0
Key38=1766:1060
Key39=1785:1067
Key40=1783:1042
Key41=1761:1040
Key42=1776:1055
Key43=1778:1056
Key44=1775:1054
Key45=1772:1051
Key46=1764:1044
Key47=1782:1046
Key48=1788:1069
Key49=1715:1025
Key50=65505:0
Key51=47:47
Key52=1777:1071
Key53=1790:1063
Key54=1779:1057
Key55=1773:1052
Key56=1769:1048
Key57=1780:1058
Key58=1784:1068
Key59=1762:1041
Key60=1760:1070
Key61=44:44
Key62=65506:0
Key63=65450:42
Key64=65032:0
Key65=32:32
Key66=65509:0
Key67=65470:0
Key68=65471:0
Key69=65472:0
Key70=65473:0
Key71=65474:0
Key72=65475:0
Key73=65476:0
Key74=65477:0
Key75=65478:0
Key76=65479:0
Key77=65407:0
Key78=65300:0
Key79=65463:55
Key80=65464:56
Key81=65465:57
Key82=65453:45
Key83=65460:52
Key84=65461:53
Key85=65462:54
Key86=65451:43
Key87=65457:49
Key88=65458:50
Key89=65459:51
Key90=65456:48
Key91=65452:44
Key92=65377:0
Key93=0:0
Key94=166:166
Key95=65480:0
Key96=65481:0
Key97=65360:0
Key98=65362:0
Key99=65365:0
Key100=65361:0
Key101=0:0
Key102=65363:0
Key103=65367:0
Key104=65364:0
Key105=65366:0
Key106=65379:0
Key107=65535:127
Key108=65421:13
Key109=65508:0
Key110=65299:0
Key111=65377:0
Key112=65455:47
Key113=65032:0
Key114=269025049:0
Key115=65515:0
Key116=65312:0
Key117=0:0
Key118=269025153:0
Key119=269025093:0
Key120=269025094:0
Key121=269025095:0
Key122=269025096:0
Key123=0:0
Key124=65027:0
Key125=65513:0
Key126=65469:61
Key127=65515:0
Key128=65517:0
Key129=0:0
Key130=0:0
Key131=0:0
Key132=0:0
Key133=0:0
Key134=0:0
Key135=0:0
Key136=0:0
Key137=0:0

[capslock]
Key8=65406:0
Key9=65307:27
Key10=49:49
Key11=50:50
Key12=51:51
Key13=52:52
Key14=53:53
Key15=54:54
Key16=55:55
Key17=56:56
Key18=57:57
Key19=48:48
Key20=45:45
Key21=61:61
Key22=65288:8
Key23=65289:9
Key24=1770:1049
Key25=1763:1062
Key26=1781:1059
Key27=1771:1050
Key28=1765:1045
Key29=1774:1053
Key30=1767:1043
Key31=1787:1064
Key32=1789:1065
Key33=1786:1047
Key34=1768:1061
Key35=1791:1066
Key36=65293:13
Key37=65507:0
Key38=1766:1060
Key39=1785:1067
Key40=1783:1042
Key41=1761:1040
Key42=1776:1055
Key43=1778:1056
Key44=1775:1054
Key45=1772:1051
Key46=1764:1044
Key47=1782:1046
Key48=1788:1069
Key49=1715:1025
Key50=65505:0
Key51=92:92
Key52=1777:1071
Key53=1790:1063
Key54=1779:1057
Key55=1773:1052
Key56=1769:1048
Key57=1780:1058
Key58=1784:1068
Key59=1762:1041
Key60=1760:1070
Key61=46:46
Key62=65506:0
Key63=65450:42
Key64=65513:0
Key65=32:32
Key66=65509:0
Key67=65470:0
Key68=65471:0
Key69=65472:0
Key70=65473:0
Key71=65474:0
Key72=65475:0
Key73=65476:0
Key74=65477:0
Key75=65478:0
Key76=65479:0
Key77=65407:0
Key78=65300:0
Key79=65429:0
Key80=65431:0
Key81=65434:0
Key82=65453:45
Key83=65430:0
Key84=65437:0
Key85=65432:0
Key86=65451:43
Key87=65436:0
Key88=65433:0
Key89=65435:0
Key90=65438:0
Key91=65439:0
Key92=65377:0
Key93=0:0
Key94=47:47
Key95=65480:0
Key96=65481:0
Key97=65360:0
Key98=65362:0
Key99=65365:0
Key100=65361:0
Key101=0:0
Key102=65363:0
Key103=65367:0
Key104=65364:0
Key105=65366:0
Key106=65379:0
Key107=65535:127
Key108=65421:13
Key109=65508:0
Key110=65299:0
Key111=65377:0
Key112=65455:47
Key113=65514:0
Key114=269025049:0
Key115=65515:0
Key116=65312:0
Key117=0:0
Key118=269025153:0
Key119=269025093:0
Key120=269025094:0
Key121=269025095:0
Key122=269025096:0
Key123=0:0
Key124=65027:0
Key125=0:0
Key126=65469:61
Key127=0:0
Key128=0:0
Key129=0:0
Key130=0:0
Key131=0:0
Key132=0:0
Key133=0:0
Key134=0:0
Key135=0:0
Key136=0:0
Key137=0:0
[shiftcapslock]
Key8=65406:0
Key9=65307:27
Key10=33:33
Key11=34:34
Key12=1712:8470
Key13=59:59
Key14=37:37
Key15=58:58
Key16=63:63
Key17=42:42
Key18=40:40
Key19=41:41
Key20=95:95
Key21=43:43
Key22=65288:8
Key23=65056:0
Key24=1738:1081
Key25=1731:1094
Key26=1749:1091
Key27=1739:1082
Key28=1733:1077
Key29=1742:1085
Key30=1735:1075
Key31=1755:1096
Key32=1757:1097
Key33=1754:1079
Key34=1736:1093
Key35=1759:1098
Key36=65293:13
Key37=65507:0
Key38=1734:1092
Key39=1753:1099
Key40=1751:1074
Key41=1729:1072
Key42=1744:1087
Key43=1746:1088
Key44=1743:1086
Key45=1740:1083
Key46=1732:1076
Key47=1750:1078
Key48=1756:1101
Key49=1699:1105
Key50=65505:0
Key51=47:47
Key52=1745:1103
Key53=1758:1095
Key54=1747:1089
Key55=1741:1084
Key56=1737:1080
Key57=1748:1090
Key58=1752:1100
Key59=1730:1073
Key60=1728:1102
Key61=44:44
Key62=65506:0
Key63=65450:42
Key64=65032:0
Key65=32:32
Key66=65509:0
Key67=65470:0
Key68=65471:0
Key69=65472:0
Key70=65473:0
Key71=65474:0
Key72=65475:0
Key73=65476:0
Key74=65477:0
Key75=65478:0
Key76=65479:0
Key77=65407:0
Key78=65300:0
Key79=65463:55
Key80=65464:56
Key81=65465:57
Key82=65453:45
Key83=65460:52
Key84=65461:53
Key85=65462:54
Key86=65451:43
Key87=65457:49
Key88=65458:50
Key89=65459:51
Key90=65456:48
Key91=65452:44
Key92=65377:0
Key93=0:0
Key94=124:124
Key95=65480:0
Key96=65481:0
Key97=65360:0
Key98=65362:0
Key99=65365:0
Key100=65361:0
Key101=0:0
Key102=65363:0
Key103=65367:0
Key104=65364:0
Key105=65366:0
Key106=65379:0
Key107=65535:127
Key108=65421:13
Key109=65508:0
Key110=65299:0
Key111=65377:0
Key112=65455:47
Key113=65032:0
Key114=269025049:0
Key115=65515:0
Key116=65312:0
Key117=0:0
Key118=269025153:0
Key119=269025093:0
Key120=269025094:0
Key121=269025095:0
Key122=269025096:0
Key123=0:0
Key124=65027:0
Key125=65513:0
Key126=65469:61
Key127=65515:0
Key128=65517:0
Key129=0:0
Key130=0:0
Key131=0:0
Key132=0:0
Key133=0:0
Key134=0:0
Key135=0:0
Key136=0:0
Key137=0:0

I made my xrdp_keyboard.ini by adding lines from here to the original config. I only replaced grp:alt_shift_toggle with grp:ctrl_shift_toggle, because I use this key combination.
What I have tried to do

Replace the contents of km-00000409.ini by the contents of km-00000419.ini.
It breaks the layouts in the opposite way.

Client layout (iOS keyboard)
Remote layout (Plasma desktop)
What I get when pressing keys

English
English
Nothing

English
Russian
Nothing

Russian
English
English letters

Russian
Russian
Russian letters

From Windows, I can only type in Russian even if the client layout is English.
At least, the contents of km-00000419.ini are functional.

Remove all the keyboards from xrdp_keyboard.ini and put the contents of [rdp_keyboard_ru] in the [default] section.

xrdp_keyboard.ini

; default
[default]
; keyboard_type and keyboard_subtype is not read for default section. It
; is only a placeholder to keep consistency. Default model/variant are
; platform dependent, and could be overridden if needed.
keyboard_type=4
keyboard_subtype=1
model=pc105
options=grp:ctrl_shift_toggle
rdp_layouts=default_rdp_layouts
layouts_map=layouts_map_ru

; user could override variant and model, but generally they should be inferred
; automatically based on keyboard type and subtype
;variant=
;model=

; A list of supported RDP keyboard layouts
rdp_layouts=default_rdp_layouts
; The map from RDP keyboard layout to X11 keyboard layout
layouts_map=default_layouts_map

[default_rdp_layouts]
rdp_layout_us=0x00000409
rdp_layout_us_dvorak=0x00010409
rdp_layout_us_dvp=0x19360409
rdp_layout_dk=0x00000406
rdp_layout_de=0x00000407
rdp_layout_es=0x0000040A
rdp_layout_fi=0x0000040B
rdp_layout_fr=0x0000040C
rdp_layout_it=0x00000410
rdp_layout_jp=0x00000411
rdp_layout_jp=0xe0010411
rdp_layout_jp=0xe0200411
rdp_layout_jp=0xe0210411
rdp_layout_kr=0x00000412
rdp_layout_no=0x00000414
rdp_layout_pl=0x00000415
rdp_layout_br=0x00000416
rdp_layout_ru=0x00000419
rdp_layout_se=0x0000041D
rdp_layout_ch=0x00000807
rdp_layout_ch_fr=0x0000100C
rdp_layout_gb=0x00000809
rdp_layout_latam=0x0000080A
rdp_layout_be=0x00000813
rdp_layout_pt=0x00000816

;  =
[default_layouts_map]
rdp_layout_us=us
rdp_layout_us_dvorak=dvorak
rdp_layout_us_dvp=us(dvp)
rdp_layout_dk=dk
rdp_layout_de=de
rdp_layout_es=es
rdp_layout_fi=fi
rdp_layout_fr=fr
rdp_layout_it=it
rdp_layout_jp=jp
rdp_layout_kr=kr
rdp_layout_no=no
rdp_layout_pl=pl
rdp_layout_br=br(abnt2)
rdp_layout_ru=ru
rdp_layout_se=se
rdp_layout_ch=ch
rdp_layout_ch_fr=ch(fr)
rdp_layout_gb=gb
rdp_layout_latam=latam
rdp_layout_be=be
rdp_layout_pt=pt

[layouts_map_ru]
rdp_layout_us=us,ru
rdp_layout_ru=us,ru

It has no effect.

Use exactly the same xrdp_keyboard.ini as here.
It has no effect.

xrdp_keyboard.ini

[default_rdp_layouts]
rdp_layout_us=0x00000409
rdp_layout_de=0x00000407
rdp_layout_fr=0x0000040C
rdp_layout_it=0x00000410
rdp_layout_jp=0x00000411
rdp_layout_jp2=0xe0010411
rdp_layout_jp3=0xe0200411
rdp_layout_jp4=0xe0210411
rdp_layout_ru=0x00000419
rdp_layout_se=0x0000041D
rdp_layout_pt=0x00000816
rdp_layout_br=0x00000416
rdp_layout_pl=0x00000415

[rdp_keyboard_ru]
keyboard_type=4
keyboard_subtype=1
model=pc105
options=grp:alt_shift_toggle
rdp_layouts=default_rdp_layouts
layouts_map=layouts_map_ru

[layouts_map_ru]
rdp_layout_us=us,ru
rdp_layout_ru=us,ru

Use km-00000419.ini generated by xrdp-genkeymap. On the remote machine, I run the following command as a non-root user:
xrdp-genkeymap km-00000419.ini
Then I replaced /etc/xrdp/km-00000419.ini with the generated file and fixed its ownership and permissions.

It has no effect. I have tried it with variants of xrdp_keyboard.ini from my tries 2 and 3.

Catch keyboard events using xev, showkey, and showkey -s. I run them as root inside a remote session. xev reacts on keypresses only when English layout is enabled on the client, it does not react to keypresses in Russian. showkey doesn't react no matter of the client layout.

I have also tried to play with km-00000409.ini, e.g., putting [noshift] section of 419.ini into [altgr] section of 409.ini, or putting only the Unicode parts of key definitions from 419.ini to 409.ini, but none of those configurations properly worked with both layouts.
So what can I do?
It seems that km-00000419.ini is ignored in my system for some reason and that the client probably uses Unicode mode of the virtual keyboard.
The Microsoft's client is the best one for iPad, I don't want to switch to an alternative.

@mushbite - I know this is an old issue, but I'm interested in looking into this if you still are. Please reply to let me know.

@matt335672 The issue was solved by using a physical keyboard on the iPad. Now I'm away from that computer and I don't have an iPad either, so I can't do any tests. I hope that I provided enough detail in my first comment.

Thanks for taking the trouble to reply @mushbite - after a three year silence on this I don't think we deserved an instant response.
The reason I've asked is we've made a lot of changes to the keyboard input for the devel version of xrdp to make problems like this easier to debug.
I don't have an iPad to work on this myself either, so I'm going to close this. For the benefit of anyone who has an iPad who ends up here:-

If anyone with an iPad want to work on this with me, please comment and I'll re-open this.
The file(s) km-00000419.ini (etc) are used on the login screen and by the Xvnc backend.
xrdp_keyboard.ini is used by the Xorg backend.

repo: neutrinolabs/xrdp


text:
Remove the wait for the ibus daemon to start

Fixes #3080 and tested by @seflerZ
The initial implementation of Uinicode input via IBus used a startup delay of 3 seconds to wait for the daemon to be ready before connecting to it.
This commit introduces a poll-wait loop which can remove the delay entirely if the daemon is up when chansrv starts the interface.

Hi @matt335672 , according to @JulyIghor 's feedback. We have a duplicate registration in input_ibus.c. Would you apply this patch to fix it up? I've tested it works.
From 29c8bfbd6d7227956c6baa944aac4b2e5649d7ba Mon Sep 17 00:00:00 2001
From: seflerZ <sefler@126.com>
Date: Thu, 30 May 2024 14:42:22 +0800
Subject: [PATCH] remove duplicate enable&disable func registration

---
 sesman/chansrv/input_ibus.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/sesman/chansrv/input_ibus.c b/sesman/chansrv/input_ibus.c
index 7b803e3a..b7ff2992 100644
--- a/sesman/chansrv/input_ibus.c
+++ b/sesman/chansrv/input_ibus.c
@@ -155,8 +155,6 @@ xrdp_input_main_loop(void *in_val)
     factory = ibus_factory_new(ibus_bus_get_connection(bus));
     g_object_ref_sink(factory);
     g_signal_connect(factory, "create-engine", G_CALLBACK(xrdp_input_ibus_create_engine), NULL);
-    g_signal_connect(factory, "enable", G_CALLBACK(xrdp_input_ibus_engine_enable), NULL);
-    g_signal_connect(factory, "disable", G_CALLBACK(xrdp_input_ibus_engine_disable), NULL);

     ibus_factory_add_engine(factory, "XrdpIme", IBUS_TYPE_ENGINE);

--
2.34.1


text:
feat: fix tests accordingly to new contract schema #NTRN-326

Task: https://hadronlabs.atlassian.net/browse/NTRN-326
Related PRs:
https://github.com/neutron-org/neutron-sdk/pull/156
https://github.com/neutron-org/neutron-dev-contracts/pull/59
https://github.com/neutron-org/neutronjsplus/pull/49
List of changes:

Fixed tests for dex_stargate and stargate_querier contracts.
Renamed dex_stargate.test.ts and stargate_queries.test.ts to dex_grpc.test.ts and grpc_queries.test.ts respectively.

Test run: https://github.com/neutron-org/neutron-tests/actions/runs/10176822282

Test run: https://github.com/neutron-org/neutron-tests/actions/runs/10355673672

repo: neutron-org/neutron-integration-tests


text:
Bluetooth microphone volume adjustment works for Sena SF2

Hello,
Just as a note as it may be useful for someone who reads this manual: I found that the in-radio setting for the Bluetooth microphone volume adjustment works with my Sena SF2 headset.
BR
Sasha

Thanks @sashahexe! I updated the doco with it

authors: new-mikha sashahexe


text:
Подпись лаунчера

Пробовал подписывать лаунчер через ksign. с дальнейшем изменением данных в hex редакторе, но ничего не получается.

... Блять, может я что-то забыл, но с какого момента это место стало тикетницей, а не багтрекером?!

брал подписанный и неподписанный файл. высчитывал разницу в размере, после добавлял в конец неподписанного файла. эти 2 байта(разница в размере). после подписал измененный неподписанный файл, и вот такая ошибка.

license: WTFPL