I see.

Please don't mind.
I had searched for similar bug report before reporting but didn't notice by then that the search result only contained Differential Revision (don't know why), so I didn't find similar tasks and reported this.
I'll keep track on T103618 and fixing.

Hi, thanks for the info.
I think this report could be a duplicate.
The case 2 in this report showcases similar problem to T103618. External volume object is manipulate in GN then it results in unstable transform.
Case 1 is a little different I think (one volume cube created in GN but can't be reused by connecting to multiple nodes). Though this could also be related to Join Geometry node.
Anyway I was thinking these are caused by same thing so I reported them together.

Thanks, have overlooked that in the manual.

In T92474#1442755, @Iliya Katueshenock (Moder) wrote:

Please do not post your reports in unrelated places. The developer will see it when there is time

In my point of view, I think the new changes would optimize the node setup and make the thinking more natural. I would want to drop a few examples here to show the differences and mention a bug (T102358) I found through the process. Also some feedback.

Thanks, good to know.

I thinked again, I notice that some user use IME as a snippet tool with dictionary. So numeric text edit is good without modify, unless adding switching IME mode auto-swtching function at Blender preference.

In T93421#1270502, @Takahiro Shizuki (sntulix) wrote:

note:
IME's mode automatic restore work at numeric edit text too. (The case: When users's manupilation goes to numeric edit text from string edit text with IME enabled.) It may be not necessary sometimes by a workflow. I think it is useful if it's automatically disabled in the numeric edit text.

@Takahiro Shizuki (sntulix) Hi, I have tested the new build in Chinese, Korean, Japanese.

• One bug, when using Chinese IME, the input / outputs "/、“ :
  
  ,which should be ”、“ :
  
  There is a redundant "/". I refer to the Microsoft Pinyin IME behaviour in notepad :
  
  Other than this, I have no idea about what should / outputs in Chinese IME.

I also tested Korean and Janpanese.

• Start Blender with Japanese IME.
  
• Click the cube's object name text field.
• Japanese IME mode doesn't auto-switch to Japanese.
• But if when in text field, manually switch the mode once, next time when after entering text field, the mode will be auto-switched.

Japanese auto-switching issue is also in 3.0 and I find ⇧ is not the hotkey to switch Japanese IME mode.
For the other two IME, auto-switching is also functional when switch to other programs.

Thanks, though I compeletely know nothing about the codes.

@Takahiro Shizuki (sntulix) Thank you for elaboration. I have seen D11929 and to me it's an amazing commit that fix a long standing issue in Blender.
According to your notes, it looks like Blender is lacking a specific event for this situation (if I comprehend correctly).

Just in case, this is how to install "Microsoft Pinyin" on Windows 10:

@Richard Antalik (ISS) @Takahiro Shizuki (sntulix) @NXSK (NXSK) I did a new bug report T93421 .

In T92410#1260340, @NXSK (NXSK) wrote:

I don't quite understand how to set IME's status to "中“ automatically. Manually switching the IME's mode, I can't reproduce this issue with MS-IME either.
I suspect the ctrl, alt, shift key may have something to do with this problem.

In T92410#1260321, @Takahiro Shizuki (sntulix) wrote:

Hi.

I do reproduce a similary malfunction everytime with the exact step at this page's description by a few different way.

Exact steps for others to reproduce the error
(Steps may need tweaking with different setup)

    Switch to Chinese input method ( microsoft).
    Click text input field
    Type something in Chinese pinyin.
    Alt-tab to different app
    Shortcuts in Blender malfunctions.

My steps is:

1. click a text box with Chinese MS-IME's alphabet mode. (IME's status Icon in system try, Chinese: "英"). By this, Focusing is set the text area and IME's status is set "中" automatically. (If it is not set automatically, change IME's mode to "中" manually with a KEY to change IME's mode changing.)
2. Keep no pressing a key and click 3D viewport and press G key. In this time, Blender don't go in Object Move modal.

Note:

• In the just switching like the above, IME's status icon does not back to "英" in 3D viewport. Usually, When focusing go to 3D Viewport, IME's status go to "英" automatically.)
• In the situation, it is seems A-Z and 0-9 Keys are handled by Windows's IME maybe. Function keys is functional.
• The key changing IME's conversion mode in Japanese, Code 243 (0xF3), Win32api constant: VK_OEM_AUTO, Meaning: OEM specific, Name: [半角／全角]

note adding:

• This situation is end by clicking other window or input some text to text box with IME word conversion.
• If some IME word conversion was made in text box, this situation is not happen.

I tested today's build and the bug is fixed it seems to me.

In my opinion, the ideal behavior should be that only when user is inputting into text field the input is handled by input methods.

@Richard Antalik (ISS) I think the way to trigger the bug is kind of diverse and in my case I'm not able to abstract a good classification.I reported a similar bug in T91355 and the reproducing way in that report is still valid as I've just tested in the daily 3.0 beta, while I can't reproduce the bug by using the steps that @NXSK (NXSK) provided (maybe I got some misunderstanding).To me, it seems like that after comfirming Chinese text input, the following user inputs are still being treated as inputing to some text field somewhere and be handled also by the input method, which leads to shot-cuts malfunction.

In T91103#1218952, @炎臻 (PrettyFireNOI7) wrote:

Though I'm not familiar with this spelling method,I suppose here the problem is the "duplicated first letter" which is similar to T80532.

Mainly I'm using is "中文(简体，中国) 微软拼音“ as in the pic above.In this case to spell "输入中文字” the input is actually "shuruzhongwenzi".

---

The spelling way the “中文(繁体，台湾) 微软仓颉" (the input method in the report) using is that firstly type in letters then hit space bar to chose Chinese charactors.Which for example, type in "jjomn" and press space bar, then the charactor "輸" should pop up.
As a result in blender also due to the problem in T80532, all the first letter in the input is duplicated and form up "j輸o入l中y文j字", in contrast , after input the result should be "輸入中文字"(Latin letters are gone).I suppose this is the error this report is mentioning.

The spelling way the “中文(繁体，台湾) 微软仓颉" (the input method in the report) using is that firstly type in letters then hit space bar to chose Chinese charactors.Which for example, type in "jjomn" and press space bar, then the charactor "輸" should pop up.
As a result in blender also due to the problem in T80532, all the first letter in the input is duplicated and form up "j輸o入l中y文j字", in contrast , after input the result should be "輸入中文字"(Latin letters are gone).I suppose this is the error this report is mentioning.

Thanks for elaboration.

Thanks for the information.I just tested 3.0 Alpha and there is no error.

In T90498#1203564, @Richard Antalik (ISS) wrote:

Can't reproduce this issue. Here is what I did:

1. Click on File > New > General
2. Set File Format to FFmpeg Video
3. Set Container to WebM
4. Set Video Codec to WEBM / VP9
5. Set Output Quality to Lossless
6. Press Ctrl+F12

Can you reproduce issue with these steps?

Just tested and no issue,thanks for replying.

In T88170#1159717, @Clément Foucault (fclem) wrote:

This is due to a difference between Cycles and EEVEE.

EEVEE applies ensure_valid_reflection on glossy normal input where Cycles only applies it on normal mapped & bump node output.

Here is an example of the same behavior in cycles.

Unfortunately, we need to use ensure_valid_reflection to avoid nasty artifacts on glossy BSDF even without bump/normal mapping (see T81070 & T78501).

We keep the same behavior when SSR is off to keep consistency.

Note that EEVEE won't distort the normals for diffuse.

In T60017#650617, @Clément Foucault (fclem) wrote:

Since last asking for information it has been 7 or more days, due to the policy of our bug tracker we will have to archive the report until the requested information is given.

Accidentally pressed Enter,rewriting the report.

Sorry for the bothering.I'll wait for tomorrow's build to check the status,if it's as usual then the new build should be coming soon (or maybe 2.92 official release).

Yeah I found the commit date is kind of old.It looks like the builds on https://builder.blender.org/download/ might get uploaded wrong,I download from there a few hours ago.

Working well for me .

In T85844#1117427, @Nicholas Rishel (nicholas_rishel) wrote:

All: this build reverts changes to that caused this issue. Please +1 if this fixes things for you or comment if there is still an issue.

In T85844#1117075, @kursad k (kursadk) wrote:

In T85844#1116568, @炎臻 (PrettyFireNOI7) wrote:

This issue might needs other stylus or Wacom tablet users.I can't find a way to enable Windows Ink only while keeping my tablet functioning.
"Use Windows Ink" setting in Wacom driver can't fix this problem and possibly my tablet is too old to work correctly without Wacom driver.

Blender offers an option to choose "Windows Ink" under "Input" settings, see if you are able to change it.

P1978 for:

In T85844#1116544, @Nicholas Rishel (nicholas_rishel) wrote:

Note to anyone looking into this issue:

This issue is a result of Win32 mouse input not being synchronized with Wintab pressure. This has been an issue before 2.92, and has reappeared because the heuristics which discourage it from happening no longer work as well because Win32 mouse input was modified to support more accurate mouse movement (smooth lines when drawing).

There is no good long term fix, the issue is how Wintab works and the compromises to support current workflows in Blender.

The fix for this issue is to use Windows Ink (may require restarting Blender).

Could you test about how the pressure is functioning with Windows Ink?

This issue might needs other stylus or Wacom tablet users.I can't find a way to enable Windows Ink only while keeping my tablet functioning.
"Use Windows Ink" setting in Wacom driver can't fix this problem and possibly my tablet is too old to work correctly without Wacom driver.

In T85733#1116549, @Nicholas Rishel (nicholas_rishel) wrote:

@Marek Trejbal (marek3ball) @炎臻 (PrettyFireNOI7) updated build to test, I believe this will resolve your remaining cursor jump issues.

In T85733#1116342, @Lillya (Lillya) wrote:

The issue has been solved for me too, using a Huion H950P.

I don't know if wintab is supposed to work on this build too, but I noticed that there's a new problem, on the start of every stroke the pressure is always 100%, causing these dots:

Console log : P1977
There is some movement me trying to open the console window at the beginning of the log and trying to switch programme window at the end.And following pictures showing my progression during the log process: