Комментарии: 24

1. Anonim

   • 16.02 2020 07:44:25

   Кабель должен быть дуал линк

   • Konstantin

     • 16.02 2020 07:46:48

     Вот я и подозреваю, что дело в кабеле. Нужно будет проверить разные или купить новый

     • Anonim

       • 16.02 2020 07:47:10

       если средней контактной группы нет то это сингл

     • Anonim

       • 16.02 2020 07:50:00

       Сфотай разьем кабеля просто

       • Konstantin

         • 16.02 2020 07:50:59

         Оно?

         • Merro

           • 16.02 2020 13:39:18

           Спасибо, а то я думал, что DVI-I - аналоговый.

           • Woddy

             • 16.02 2020 13:44:45

             Он комбо Слева 4 штыречка это rgb обычный. А справа это цифровые линии

           • Konstantin

             • 16.02 2020 14:49:10

             Чисто аналоговых я никогда не видел. А вот чисто цифровые бывают

2. Dmytro

   • 16.02 2020 09:23:48

   Dvi может быть dual link или single. Даже если у вас урезанная версия, можете "разогнать" используя CRU

   • Setpf

     • 16.02 2020 09:26:50

     Инициализируешь сокет по ип\порту. Напихиваешь бинарный массив данными и передаешь указатель, после чего говоришь ЕБОШЬ!111 Ждешь пока ТхДан будет Попутно проверяешь состояние сокета. Закрыт, в процессе, коннект Таймауты все на пользователе. Я просто изучаю через отладчик. И заметил, что если я долго сижу на брикпоинте - все подвисает. Клиент перестает отправлять данные на серв. Предположил, что у кого либо навертывается TCP канал, скорее всего на сервере.

     • Cyberzx

       • 16.02 2020 09:27:14

       а что за чип?

       • Setpf

         • 16.02 2020 09:27:24

         F67J60

         • Cyberzx

           • 16.02 2020 09:28:38

           http://ww1.microchip.com/downloads/en/devicedoc/39762f.pdf вот этот?

           • Setpf

             • 16.02 2020 09:32:23

             Да, у этого просто ног поболее. Ща вот накатил новую версию (была 2.2.8 стала 2.2.12 И та же самая фигня. Вот это условие - проходит.

             

     • Setpf

       • 16.02 2020 09:30:09

       Нашел то, что клиент не возвращает TxDone, но и соединение не теряет. Дописал простейший таймаут, что бы если 5 секунд не было TxDone - рвется соединение. В итоге какая-то простите хуита началась. TxDone иногда как оказалось возвращается, а при вызове TCP_Close, оно почему то не закрывается. Из всей кучи этих непоняток, решил пока выяснить, а не должен ли сам TCP находить потерянное соединение и грохать его.

       • Dmytro

         • 16.02 2020 09:30:11

         Custom resolution utility

       • Cyberzx

         • 16.02 2020 09:33:12

         сам он не умеет это делать. в винде, например, ОС присылает RST, если выдернуть кабель. драйвер определяет, что был link-down и всем соединениям шлёт закрытие коннекта. а в линуксе никто тебе RST не пришёл. можно выдернуть кабель, потом через полчаса вставить обратно и продолжать пользоваться соединением (например SSH)

         • Setpf

           • 16.02 2020 09:33:57

           Т.е. ответственность за закрытие соединения на пользователе Ок.

           • Cyberzx

             • 16.02 2020 09:34:34

             вот здесь я был не прав. сокет не закрывается на отсутсвие аков. ну да. у тебя коннекта может не быть хоть сутки.

             • Setpf

               • 16.02 2020 09:35:29

               Только я немножко не понимаю концепцию, TCP - гарантирует доставку. Т.е. он как минимум не должен забирать еще данные, попутно херя предыдущие. Или я что то не правильно воспринимаю? Не должен выставлять TxDone, если ничерта не доставлено.

               • Cyberzx

                 • 16.02 2020 09:36:14

                 я так подозреваю TxDone это не уровень TCP, а уровень IP/Ethernet

                 • Setpf

                   • 16.02 2020 09:36:33

                   Не это я сократил просто он TCP_SendDone

   • Konstantin

     • 16.02 2020 09:28:31

     Что такое CRU? Утилита?

     • Dmytro

       • 16.02 2020 09:29:54

       Да, редактирует частоты в видео интерфейсе, позволяя передать нестандартное или больше чем максимальное разрешение.