Ros-dev

ros-dev@reactos.org

2 participants
5792 discussions

Committing to trunk
by Aleksey Bragin 28 Jul '09

28 Jul '09

Hello, our debug buildslave is currently offline, I'd like to ask developers to abstain from committing to trunk till it comes back online (hopefully we can thing something up, have a spare buildslave, turn release buildslave into a debug one or something). Otherwise we may miss potential regressions. Thanks for understanding, Aleksey Bragin.

1 1

[BUG] Utterly incorrect implementation of input device coordinates.
by codeforfood＠pulseforce.com 27 Jul '09

27 Jul '09

Here's the information required to patch the incorrect implementation. Abstract: - SendInput()/NtUserSendInput() broken: --- Relative hardware mouse input "working", but not well implemented due to lack of modifying the travel distance using cursor acceleration and movement speeds (I've provided info on this as well below), input-virtual vs screen-real coordinates (even in the relative moves), etc. The two coordinate spaces are not the same thing! --- Absolute hardware mouse input broken (used by things like touchscreens), by a complete misunderstanding of how the virtual input device coordinate space works (it's NOT in ANY way a 1:1 map that's translatable to the screen, but the function uses it this way everywhere!) read below for full info since this is the serious problem. - SetCursorPos() broken (should NOT be using SendInput() since that's pointless and ineffective and is meant for the hardware input queue, we already have the desired coordinates and should move the cursor directly; and even its use of SendInput() is incorrect since it should FIRST convert the desired SCREEN coordinates to absolute-INPUT-coordinate-space), BUT since it's using the broken SendInput() (which currently doesn't know that absolute input coordinates have NOTHING to do with screen coordinates) it works correctly and will place cursors at the right location. This will have to be changed when SendInput() is patched; preferrably to a direct cursor update (elaborated in the recap below, before the log), rather than the current indirect/slow approach which places a message in the serial (as in serial-processing, first-come-first-serve) mouse-input-translation queue. So to recap: - Need to improve relative movement (to handle acceleration and mouse speed modifiers) - Need to change the code everywhere where you've been thinking that input coordinates are the same as screen coordinates (most likely only within SetCursorPos(), and SendInput()/NtUserSendInput()) - Absolute cursor placement inside SendInput() needs to be rewritten to convert absolute input-space coordinates to absolute screen-space coordinates (quite an easy change) using the algorithm I provide below, which is what Windows uses internally. - SetCursorPos() needs to COMPLETELY stop using SendInput() and instead manipulate the cursor X/Y struct directly, or equivalent methods, instead of injecting itself into the input queue. Alternatively, if it keeps using the input queue, it needs a reverse-algorithm to turn the desired screen-coordinates into virtual inputspace-coordinates, such as int mouseinput_abs_x_or_y_pos = (((65536 * screen_x_or_y_pos) / screen_width_or_height) + 1). The +1 is necessary for proper rounding. However, I see no reason to use the input queue within this function as that involves much more work than simply writing the cursor's location directly (which is what SendInput EVENTUALLY gets around to doing after LOTS of processing, and saving on cycles/jumps/calls is GOOD ;)). All details on how to fix these things are in the below log. Let me know if there's any questions. Log (most unrelated discussions/events snipped and long breaks between explaining different details have been separated with "..."): 19:56 Yewbacca . I am sure you've implemented SetCursorPos() incorrectly. Checking your source code for it at cursor.c:280. This function is SUPPOSED to take a SCREEN X/Y coordinate (ie X=1400, Y=800 on a 1440x900 screen, and then moves the cursor location directly, without emulating mouse movement. 19:57 Yewbacca . Instead, your version calls SendInput() with the x/y unmodified, that's awful. SendInput()'s absolute space is a virtual desktop square that stretches from 0-65535 in each direction and will not even be remotely close to what the intended destination is. 19:57 _0_ . sounds like a patch is in order Yewbacca 19:57 _0_ . :P 19:58 +encoded . Yewbacca, file bug report! 19:58 Yewbacca . _0_ Well I'd have to know how you're writing the cursor position inside NtSendUserInput etc. 19:58 Yewbacca . Or file a bug report, I'll do that. 20:01 Yewbacca . Related to this, Windows actually uses a slightly unexpected algorithm for its SendInput() absolute-mode coordinates-to-screen conversion. 20:01 Yewbacca . int destx_or_y = (screen_width_or_height * x_or_y_abs_coord) / 65536 20:01 Yewbacca . If you want pixel precise SendInput() that works as on windows you'd have to verify this. I'll bug report that too. 20:02 +encoded . <3 Yewbacca 20:02 Yewbacca . :) 20:02 +encoded . you can ofcourse see the source code of NtSendUserInput 20:03 Yewbacca . Yeah I was about to check that to make sure it's not already correct 20:04 +encoded . its in \subsystems\win32\win32k\ntuser\input.c 20:04 Yewbacca . Ah thanks, that saves a slow grep. 20:05 +encoded . wait opps 20:05 . garrythefish_ [n=fisher@unaffiliated/garrythefish] has joined #reactos 20:05 +encoded . oh well, nvm me 20:05 garrythefish_ . community choice award today. hope you guys win. :D 20:10 Yewbacca . Okay after brief confusion I noticed that IntMouseInput() contains the actual logic for mouse-type input to SendInput(), input.c:1081. Time to check it. ... 20:14 Yewbacca . Okay now I'm really confused. I read through IntMouseInput() from input.c:1081-1333 and unless I missed a call to a driver-coordinates-to-screen-coordinates somewhere, this function is miscoded as well. That'd mean that SetCursorPos() would work correctly since SendInput() would work incorrectly, and that normal SendInput() calls that expect a 0 to 65535 range would not work at all. 20:15 Yewbacca . It really seems to directly write the pointers for cursor X and Y with the values it has received 20:15 Yewbacca . with no conversion whatsoever 20:15 Yewbacca . even though the incoming values are in a 0 to 65535 range 20:15 Yewbacca . of that virtual space ... 20:16 Yewbacca . Basically for anyone unfamiliar with it, the driver implements a virtual space for the cursor to either move relatively within, or absolutely, to allow things like touchscreens to function easily (they'd just have to SendInput() their current position as a percentage of the 65535 range). 20:16 Yewbacca . So all incoming absolute-mode coordinates must be converted to screen coordinates, and microsoft does it with int destx_or_y = (screen_width_or_height * x_or_y_abs_coord) / 65536 20:17 Yewbacca . I'm going to re-read it again to see if I missed some conversion call. If not, that'll be 2 reports. Quite easy fixes luckily. 20:18 +encoded . <3 Yewbacca 20:18 Yewbacca . I think the reason you got by this far is because the HARDWARE mouse sends coordinates relatively 20:18 Yewbacca . The problem'd only appear with absolute input like touchscreens. And since SendInput()'s absolute mode is broken that means program's SetCursorPos() would work, so it's doubly broken and would only cause problems for absolute hardware-input (again, touchscreens mainly). 20:18 Yewbacca . :P 20:19 Yewbacca . Reading again 20:20 +encoded . Yewbacca, we can use someone like you who has knowledge of windows internals 20:20 Yewbacca . Maybe, right now I'm tied up with some major work :) ... 20:28 Yewbacca . Alright I've finished checking everything. IntMouseInput() stretches from input.c:1081-1333 and is the function that's called when NtUserSendInput()/SendInput() receives a mouse-type event. At line 1140 it grabs the pointer to the cursor's X/Y struct with IntGetCursorLocation(WinSta, &MousePos). Then we get to the significant errors. 20:29 Yewbacca . At lines 1146-1150 it incorrectly writes the virtual x/y of the INPUT coordinate system right into the memory holding the SCREEN x/y cursor location 20:30 Yewbacca . At lines 1151-1155 it handles relative movement but doesn't take into account cursor acceleration and movement speed (those settings we all love in the control panel->mouse), which in turn can increase the movement distance as much as 4 times the input value. 20:31 Yewbacca . Those two behaviours right there would need to be patched. The first should determine the destination on the screen through int destx_or_y = (screen_width_or_height * x_or_y_abs_coord) / 65536. The latter should implement handling for cursor acceleration (check MSDN, it describes acceleration on SendInput()). 20:32 Yewbacca . And lastly, SetCursorPos() (forgot which file it's in) needs to *completely* skip the SendInput() baloney that it's doing right now (http://pastebin.com/d2db76985) and just directly grab the cursor X/Y pointer and update it in a simple assignment, AFTER checking that it's in range of course (otherwise clamping it to the screen). 20:33 +Lone_Rifle . Yewbacca, suggest that you subscribe to ros-dev and retype or copy-paste your findings there, it's quite a bit of text to go through in one sitting 20:33 Yewbacca . Oh yeah and if you wanna be 100% complete, also implement a check for ClipCursor() and don't allow the cursor to move outside that, no matter if it's from hardware input or SetCursorPos(). If it's outside, it should be clamped to the nearest inside value. 20:34 Yewbacca . Lone_Rifle Yeah, I agree and was going to submit it. I'll do that now. ... 20:37 Yewbacca . Acceleration is described at http://msdn.microsoft.com/en-us/library/ms646273(VS.85).aspx (info for the MOUSEINPUT struct). I'll submit this log to the mailing list. =EOF=

2 1

[ros-diffs] [ros-arm-bringup] 42250: - Fix a ridiculous copy-paste-error-while-writing-the-commit-log error. Sorry for breaking the build!
by James Tabor 27 Jul '09

27 Jul '09

Oh, okay, I'll do the same,,,,, oh,,,,,, never mind,,,,,, I do that too.

1 0

Re: [ros-dev] [ros-diffs] [ros-arm-bringup] 42220: - This is a HIGH RISK patch.
by Gabriel ilardi 26 Jul '09

26 Jul '09

Hi Everyone, I've encountered this assert after restarting in 2nd stage. Rev 42235, vbox 3.0.2, "cont" lets ros continue to 3rd stage: It's not random, I've tried three times with the same result. Best regards, Gabriel. Assertion 'EndPfn == MiGetPfnEntry(Page + 1)' failed at ntoskrnl\mm\freelist.c line 301 PuTTYEntered debugger on embedded INT3 at 0x0008:0x808c1502. kdb:> bt Eip: <NTOSKRNL.EXE:c1503 (lib\rtl\i386\debug_asm.S:33 (DbgBreakPoint@0))> Frames: <NTOSKRNL.EXE:7df7e (ntoskrnl/mm/freelist.c:306 (MiFindContiguousPages@20))> <NTOSKRNL.EXE:75ef8 (ARMÂ³::CONTMEM:156 (MiFindContiguousMemory@20))> <NTOSKRNL.EXE:75fcc (ARMÂ³::CONTMEM:232 (MiAllocateContiguousMemory@20))> <NTOSKRNL.EXE:761d0 (ARMÂ³::CONTMEM:382 (MmAllocateContiguousMemorySpecifyCache@32))> <HAL.DLL:2a72> <usbdriver.sys:1610f (drivers/usb/nt4compat/usbdriver/td.c:51 (init_td_pool))> <usbdriver.sys:162c5 (drivers/usb/nt4compat/usbdriver/td.c:266 (expand_pool_list))> <usbdriver.sys:163da (drivers/usb/nt4compat/usbdriver/td.c:233 (init_td_pool_list))> <usbdriver.sys:100c9 (drivers/usb/nt4compat/usbdriver/uhci.c:1033 (uhci_init_sc edule))> <usbdriver.sys:10505 (drivers/usb/nt4compat/usbdriver/uhci.c:818 (uhci_alloc))> <usbdriver.sys:1076a (drivers/usb/nt4compat/usbdriver/uhci.c:659 (uhci_probe))> <usbdriver.sys:1082b (drivers/usb/nt4compat/usbdriver/uhci.c:3861 (DriverEntry@ ))> <NTOSKRNL.EXE:4a75b (ntoskrnl/io/iomgr/driver.c:1389 (IopCreateDriver@24))> <NTOSKRNL.EXE:49b4d (ntoskrnl/io/iomgr/driver.c:467 (@IopInitializeDriverModule 20))> <NTOSKRNL.EXE:4ac88 (ntoskrnl/io/iomgr/driver.c:1765 (IopLoadUnloadDriver@4))> <NTOSKRNL.EXE:4ae20 (ntoskrnl/io/iomgr/driver.c:1843 (NtLoadDriver@4))> <NTOSKRNL.EXE:b9afc (ntoskrnl\ke\i386\trap.s:244 (KiFastCallEntry))> <NTOSKRNL.EXE:be4a5 (obj-i386\ntoskrnl\ex\zw.S:929 (ZwLoadDriver))> <NTOSKRNL.EXE:4b3c2 (ntoskrnl/io/iomgr/drvrlist.c:540 (@IopInitializeSystemDriv rs@0))> <NTOSKRNL.EXE:d9948 (ntoskrnl/io/iomgr/iomgr.c:529 (IoInitSystem@4))> <NTOSKRNL.EXE:36846 (ntoskrnl/ex/init.c:1711 (Phase1InitializationDiscard@4))>- - Press q to abort, any other key to continue --- <NTOSKRNL.EXE:37567 (ntoskrnl/ex/init.c:1921 (Phase1Initialization@4))> <NTOSKRNL.EXE:af375 (ntoskrnl/ps/thread.c:158 (PspSystemThreadStartup@8))> <NTOSKRNL.EXE:b92f6 (ntoskrnl\ke\i386\ctxswitch.S:306 (KiThreadStartup@156))> kdb:> _________________________________________________________________ Condividi i tuoi ricordi online con chi vuoi tu. http://www.microsoft.com/italy/windows/windowslive/products/photos-share.as…

1 0

Re: [ros-dev] [ros-diffs] [cgutman] 42225: - Begin using ws2help_new - I have tested this with various applications in ROS - Part 2 of 2
by Aleksey Bragin 26 Jul '09

26 Jul '09

That's a good first step into using proper winsock! WBR, Aleksey Bragin. On Jul 26, 2009, at 10:00 AM, cgutman(a)svn.reactos.org wrote: > Author: cgutman > Date: Sun Jul 26 08:00:32 2009 > New Revision: 42225 > > URL: http://svn.reactos.org/svn/reactos?rev=42225&view=rev > Log: > - Begin using ws2help_new > - I have tested this with various applications in ROS > - Part 2 of 2 > > Added: > trunk/reactos/dll/win32/ws2help/ (props changed) > - copied from r42178, trunk/reactos/dll/win32/ws2help_new/ > Removed: > trunk/reactos/dll/win32/ws2help_new/

1 0

Re: [ros-dev] [ros-diffs] [sginsberg] 42218: - Fix most freeldr compilation issues, most notably: - Define structure packing correctly for msvc. - Define Ke386EraseFlags for msvc too. - Don't return a function returning void in a function returning void. - VideoFadeIn: Don't rely on some fishy gcc extension for allocating memory from the stack -- just use the heap instead. - Winldr remains
by Timo Kreuzer 26 Jul '09

26 Jul '09

sginsberg(a)svn.reactos.org schrieb: > Author: sginsberg > Date: Sat Jul 25 22:17:23 2009 > New Revision: 42218 > > URL: http://svn.reactos.org/svn/reactos?rev=42218&view=rev > Log: > - Fix most freeldr compilation issues, most notably: > - Define structure packing correctly for msvc. > - Define Ke386EraseFlags for msvc too. > hint: __writeeflags()

1 0

IServ
by Colin Finck 23 Jul '09

23 Jul '09

Hello all, Now that also the mail migration is more or less completed, let me introduce you to IServ. IServ is a Groupware solution, which we will be using now for managing E-Mail accounts, appointments, contact data and a common FTP space. It will be available to everybody, who is qualified for a @reactos.org E-Mail address. (so basically developers with SVN access and official testers) For your @reactos.org E-Mail address, IServ provides a 250 MB mailbox. You can send and receive E-Mails over the Web interface and also over POP3, IMAP and SMTP. The Web interface also offers an option to set up a redirection if you want to use another mailbox for incoming mails. Files can be uploaded either over the Web interface or over FTP. Our IServ Web interface is available at http://iserv.reactos.org. The POP3, IMAP, SMTP and FTP services can be accessed over the same domain. If you have an @reactos.org E-Mail address, but no IServ account yet, I will shortly send you your account name along with an initial password. Your account name will also serve as your primary E-Mail address from now on. (i.e. colin.finck(a)reactos.org). Of course, your previous E-Mail aliases will continue to work. They are linked to your primary address now. As most of you used a redirection from your @reactos.org address to another mailbox, I've set up these redirections in the Web interface already. You can change them anytime. A big thanks go to Martin von Wittich and the IServ GmbH, who provided us with a site license for IServ and helped us with the setup. Also thank our translators Amine Khaldi, Gabriel Ilardi and Alex/care2debug for the French, Italian, Spanish and Russian translations of the Web interface. Best regards, Colin

2 1

Let's push winetests farther!
by Jérôme Gardou 23 Jul '09

23 Jul '09

As you all know, reactos is tested against the wine test suite. While this is a great tool, I think this is not enough to be sure that ReactOS is fully tested. I've been trying to fix some kernel32 tests. As you all know, in ReactOS it is written on top of ntdll. So I wanted to fix some tests, and then a question arose : is it that kernel32 calls ntdll the wrong way, or is it that ntdll does the wrong job? The only way to verify this would be to test kernel32.dll out of reactOS, meaning replacing the windows one with the reactos one, and run the test. To be brief : I think that a weekly "reactos dlls against windows" test would be very helpful to be sure that things are done the right way! I began with the kernel32:file winetest. I managed to not make it crash when used on winXP, the resulting patch is there : http://www.reactos.org/bugzilla/show_bug.cgi?id=4728 and the result of this test is attached there. As miracles happen, it also fixes some tests on ReactOS. Seems like this is a good approach. Jérôme Gardou (aka zefklop on IRC and forums)

2 3

how can I create my own code page?
by Creatxr 22 Jul '09

22 Jul '09

hi, I have a question: how can I create my own code page? where can I get the documents about it? thanks. creatxr

3 8

Re: [ros-dev] [ros-diffs] [dchapyshev] 42012: - Samplify SwitchToThread and QueueUserWorkItem - Remove unneeded InternalWorkItemTrampoline function and QUEUE_USER_WORKITEM_CONTEXT structure - Other small changes
by Thomas Bluemel 22 Jul '09

22 Jul '09

This explains why we are using a trampoline function and not just typecast there... Is there a reason you changed this? - Thomas dchapyshev(a)svn.reactos.org wrote: > - /* NOTE: Don't use Function directly since the callback signature > - differs. This might cause problems on certain platforms... */ > - Status = RtlQueueWorkItem(InternalWorkItemTrampoline, > - WorkItemContext,

8 11

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev